Network Working Group S. Shanmugham
Request for Comments: 4463 Cisco Systems, Inc.
Category: Informational P. Monaco
Nuance Communications
B. Eberman
Speechworks Inc.
April 2006
A Media Resource Control Protocol (MRCP)
Developed by Cisco, Nuance, and Speechworks
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
Note that this document uses a MIME type 'application/mrcp' which has not been registered with the IANA, and is therefore not recognized as a standard IETF MIME type. The historical value of this document as an ancestor to ongoing standardization in this space, however, makes the publication of this document meaningful.
この文書は、IANAに登録されていないMIMEタイプ「アプリケーション/ MRCP」を使用し、したがって標準IETF MIMEタイプとして認識されないことに留意されたいです。この空間で進行中の標準化の祖先として、この文書の履歴値が、しかし、意味のある本文書の発行を行います。
Abstract
抽象
This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.
この文書では、Cisco Systems、Inc.の、ニュアンスコミュニケーションズ、およびSpeechworksによって共同開発されたメディアリソース制御プロトコル（MRCP）は、株式会社は、それは、この分野での更なるIETF開発のための入力としてRFCとして公開されて説明します。
MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol).
MRCPは、ネットワークを介して、音声合成、認識装置、信号発生器、信号検出器、ファックスサーバなどのようなメディアサービスのリソースを制御します。このプロトコルは、RTP（リアルタイムプロトコル）などの外部メディアストリーミングデバイスへの制御接続の確立を支援RTSP（リアルタイムストリーミングプロトコル）またはSIP（セッション開始プロトコル）などのストリーミングプロトコル、およびメディア配信メカニズムで動作するように設計されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Architecture ....................................................4
2.1. Resources and Services .....................................4
2.2. Server and Resource Addressing .............................5
3. MRCP Protocol Basics ............................................5
3.1. Establishing Control Session and Media Streams .............5
3.2. MRCP over RTSP .............................................6
3.3. Media Streams and RTP Ports ................................8
4. Notational Conventions ..........................................8
5. MRCP Specification ..............................................9
5.1. Request ...................................................10
5.2. Response ..................................................10
5.3. Event .....................................................12
5.4. Message Headers ...........................................12
6. Media Server ...................................................19
6.1. Media Server Session ......................................19
7. Speech Synthesizer Resource ....................................21
7.1. Synthesizer State Machine .................................22
7.2. Synthesizer Methods .......................................22
7.3. Synthesizer Events ........................................23
7.4. Synthesizer Header Fields .................................23
7.5. Synthesizer Message Body ..................................29
7.6. SET-PARAMS ................................................32
7.7. GET-PARAMS ................................................32
7.8. SPEAK .....................................................33
7.9. STOP ......................................................34
7.10. BARGE-IN-OCCURRED ........................................35
7.11. PAUSE ....................................................37
7.12. RESUME ...................................................37
7.13. CONTROL ..................................................38
7.14. SPEAK-COMPLETE ...........................................40
7.15. SPEECH-MARKER ............................................41
8. Speech Recognizer Resource .....................................42
8.1. Recognizer State Machine ..................................42
8.2. Recognizer Methods ........................................42
8.3. Recognizer Events .........................................43
8.4. Recognizer Header Fields ..................................43
8.5. Recognizer Message Body ...................................51
8.6. SET-PARAMS ................................................56
8.7. GET-PARAMS ................................................56
8.8. DEFINE-GRAMMAR ............................................57
8.9. RECOGNIZE .................................................60
8.10. STOP .....................................................63
8.11. GET-RESULT ...............................................64
8.12. START-OF-SPEECH ..........................................64
8.13. RECOGNITION-START-TIMERS .................................65
8.14. RECOGNITON-COMPLETE ......................................65
8.15. DTMF Detection ...........................................67
9. Future Study ...................................................67
10. Security Considerations .......................................67
11. RTSP-Based Examples ...........................................67
12. Informative References ........................................74
Appendix A. ABNF Message Definitions ..............................76
Appendix B. Acknowledgements ......................................84
The Media Resource Control Protocol (MRCP) is designed to provide a mechanism for a client device requiring audio/video stream processing to control processing resources on the network. These media processing resources may be speech recognizers (a.k.a. Automatic-Speech-Recognition (ASR) engines), speech synthesizers (a.k.a. Text-To-Speech (TTS) engines), fax, signal detectors, etc. MRCP allows implementation of distributed Interactive Voice Response platforms, for example VoiceXML [6] interpreters. The MRCP protocol defines the requests, responses, and events needed to control the media processing resources. The MRCP protocol defines the state machine for each resource and the required state transitions for each request and server-generated event.
メディアリソース制御プロトコル（MRCP）は、ネットワーク上の処理リソースを制御するために、オーディオ/ビデオ・ストリーム処理を必要とするクライアントデバイスのためのメカニズムを提供するように設計されています。これらのメディア処理リソースは、MRCP、分散対話型音声の実装を可能にする音声認識（別名自動音声認識（ASR）エンジン）、音声合成（別名音声合成（TTS）エンジン）などファックス、信号検出器であってもよく、応答プラットフォーム、例えばVoiceXMLの[6]通訳。 MRCPプロトコルは、メディア処理リソースを制御するために必要な要求、応答、およびイベントを定義します。 MRCPプロトコルは、各リソースと各要求とサーバが生成したイベントのために必要な状態遷移のための状態機械を定義します。
The MRCP protocol does not address how the control session is established with the server and relies on the Real Time Streaming Protocol (RTSP) [2] to establish and maintain the session. The session control protocol is also responsible for establishing the media connection from the client to the network server. The MRCP protocol and its messaging is designed to be carried over RTSP or another protocol as a MIME-type similar to the Session Description Protocol (SDP) [5].
MRCPプロトコルは、[2]のセッションを確立し、維持するために、制御セッションがサーバーで確立された方法を対処し、リアルタイムストリーミングプロトコル（RTSP）に依存していません。セッション制御プロトコルは、ネットワーククライアントからサーバーへのメディア接続を確立する責任があります。 MRCPプロトコルおよびそのメッセージは、RTSPまたはセッション記述プロトコル（SDP）に類似MIME型など他のプロトコルを介して搬送されるように設計されている[5]。
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 [8].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[8]。
The system consists of a client that requires media streams generated or needs media streams processed and a server that has the resources or devices to process or generate the streams. The client establishes a control session with the server for media processing using a protocol such as RTSP. This will also set up and establish the RTP stream between the client and the server or another RTP endpoint. Each resource needed in processing or generating the stream is addressed or referred to by a URL. The client can now use MRCP messages to control the media resources and affect how they process or generate the media stream.
システムは、生成されたメディアストリームを必要とするか、またはメディアストリームを処理必要とするクライアントおよび処理したり、ストリームを生成するためのリソースやデバイスを持っているサーバーで構成されています。クライアントは、RTSPのようなプロトコルを使用して、メディア処理のためにサーバとの制御セッションを確立します。これも設定し、クライアントとサーバまたは別のRTPエンドポイント間のRTPストリームを確立します。処理またはストリームを生成するのに必要な各リソースは、アドレスまたはURLによって参照されます。クライアントは、メディアリソースを制御し、それらが処理する方法に影響を与えるか、メディアストリームを生成するMRCPメッセージを使用することができます。
|--------------------|
||------------------|| |----------------------|
|| Application Layer|| ||--------------------||
||------------------|| || TTS | ASR | Fax ||
|| ASR/TTS API || ||Plugin|Plugin|Plugin||
||------------------|| || on | on | on ||
|| MRCP Core || || MRCP | MRCP | MRCP ||
|| Protocol Stack || ||--------------------||
||------------------|| || RTSP Stack ||
|| RTSP Stack || || ||
||------------------|| ||--------------------||
|| TCP/IP Stack ||========IP=========|| TCP/IP Stack ||
||------------------|| ||--------------------||
|--------------------| |----------------------|
MRCP client Real-time Streaming MRCP media server
MRCPクライアントリアルタイムストリーミングMRCPメディアサーバー
The server is set up to offer a certain set of resources and services to the client. These resources are of 3 types.
サーバーがクライアントにリソースとサービスの特定のセットを提供するように設定されています。これらのリソースは、3種類があります。
Transmission Resources
伝送リソース
These are resources that are capable of generating real-time streams, like signal generators that generate tones and sounds of certain frequencies and patterns, and speech synthesizers that generate spoken audio streams, etc.
これらは、など特定の周波数やパターンのトーンとサウンドを生成する信号発生器と、話のオーディオストリームを生成する音声合成、のようなリアルタイムのストリームを生成することが可能である資源、あります
Reception Resources
レセプションリソース
These are resources that receive and process streaming data like signal detectors and speech recognizers.
これらは、受信リソースと信号検出器と、音声認識などのプロセスのストリーミングデータです。
Dual Mode Resources
デュアルモードリソース
These are resources that both send and receive data like a fax resource, capable of sending or receiving fax through a two-way RTP stream.
これらは両方とも、双方向RTPストリームを通じてファックスを送信または受信することが可能なファックス・リソースなどのデータを、送信および受信リソースです。
The server as a whole is addressed using a container URL, and the individual resources the server has to offer are reached by individual resource URLs within the container URL.
全体として、サーバは、コンテナのURLを使用してアドレス指定され、サーバが提供している個々のリソースは、コンテナのURL内の個々のリソースのURLが到達しています。
RTSP Example:
RTSP例：
A media server or container URL like,
メディアサーバーまたはコンテナのURLのように、
rtsp://mediaserver.com/media/
RTSP：//mediaserver.com/media/
may contain one or more resource URLs of the form,
フォームの1つ以上のリソースのURLを含むことができ、
rtsp://mediaserver.com/media/speechrecognizer/ rtsp://mediaserver.com/media/speechsynthesizer/ rtsp://mediaserver.com/media/fax/
RTSP：//mediaserver.com/media/speechrecognizer/ RTSP：//mediaserver.com/media/speechsynthesizer/ RTSP：//mediaserver.com/media/fax/
The message format for MRCP is text based, with mechanisms to carry embedded binary data. This allows data like recognition grammars, recognition results, synthesizer speech markup, etc., to be carried in the MRCP message between the client and the server resource. The protocol does not address session control management, media management, reliable sequencing, and delivery or server or resource addressing. These are left to a protocol like SIP or RTSP. MRCP addresses the issue of controlling and communicating with the resource processing the stream, and defines the requests, responses, and events needed to do that.
MRCPのメッセージフォーマットは、埋め込まれたバイナリデータを搬送する機構を有するテキストベースです。これは、認識文法、認識結果、シンセサイザーの音声マークアップ、など、などのデータは、クライアントとサーバーのリソース間のMRCPメッセージで運ばれることを可能にします。プロトコルは、セッション制御管理、メディア管理、信頼性の高いシーケンシング、および配信サーバーまたはリソースのアドレス指定には対応していません。これらは、SIPやRTSPなどのプロトコルに残されています。 MRCPは、制御およびストリームを処理リソースと通信の問題に対処し、それを行うために必要な要求、応答、およびイベントを定義します。
The control session between the client and the server is established using a protocol like RTSP. This protocol will also set up the appropriate RTP streams between the server and the client, allocating ports and setting up transport parameters as needed. Each control session is identified by a unique session-id. The format, usage, and life cycle of the session-id is in accordance with the RTSP protocol. The resources within the session are addressed by the individual resource URLs.
クライアントとサーバ間の制御セッションは、RTSPなどのプロトコルを使用して確立されます。このプロトコルは、適切なRTPポートを割り当て、必要に応じて、トランスポートパラメータの設定、サーバとクライアントとの間でストリームを設定します。各制御セッションはユニークなセッションIDによって識別されます。セッションIDの形式、使用、およびライフサイクルは、RTSPプロトコルに従うものです。セッション内のリソースは、個々のリソースのURLによって対処されています。
The MRCP protocol is designed to work with and tunnel through another protocol like RTSP, and augment its capabilities. MRCP relies on RTSP headers for sequencing, reliability, and addressing to make sure that messages get delivered reliably and in the correct order and to the right resource. The MRCP messages are carried in the RTSP message body. The media server delivers the MRCP message to the appropriate resource or device by looking at the session-level message headers and URL information. Another protocol, such as SIP [4], could be used for tunneling MRCP messages.
MRCPプロトコルはで動作するように設計されており、トンネルRTSPのような他のプロトコルを介して、その能力を増強します。 MRCPは、配列決定のためにRTSPヘッダーに依存して、信頼性、およびメッセージは、正しい順序で、右のリソースに確実に届けますことを確認して対処します。 MRCPメッセージは、RTSPメッセージ本体に搭載されています。メディアサーバは、セッションレベルメッセージヘッダーとURLの情報を見て、適切なリソースまたはデバイスにMRCPメッセージを配信します。 SIPなどの別のプロトコルは、[4]、MRCPメッセージをトンネリングするために使用することができます。
RTSP supports both TCP and UDP mechanisms for the client to talk to the server and is differentiated by the RTSP URL. All MRCP based media servers MUST support TCP for transport and MAY support UDP.
RTSPサーバに話をするクライアントのTCPとUDPのメカニズムの両方をサポートし、RTSP URLによって区別されます。すべてのMRCPベースのメディアサーバーは、トランスポートにTCPをサポートしなければならないし、UDPをサポートするかもしれません。
In RTSP, the ANNOUNCE method/response MUST be used to carry MRCP request/responses between the client and the server. MRCP messages MUST NOT be communicated in the RTSP SETUP or TEARDOWN messages.
RTSPでは、ANNOUNCEメソッド/応答は、クライアントとサーバの間のMRCP要求/応答を運ぶために使用しなければなりません。 MRCPメッセージは、RTSP SETUPまたはTEARDOWNメッセージで伝えてはなりません。
Currently all RTSP messages are request/responses and there is no support for asynchronous events in RTSP. This is because RTSP was designed to work over TCP or UDP and, hence, could not assume reliability in the underlying protocol. Hence, when using MRCP over RTSP, an asynchronous event from the MRCP server is packaged in a server-initiated ANNOUNCE method/response communication. A future RTSP extension to send asynchronous events from the server to the client would provide an alternate vehicle to carry such asynchronous MRCP events from the server.
現在、すべてのRTSPメッセージは、要求/応答であるとRTSPでの非同期イベントのサポートはありません。 RTSPは、基本的なプロトコルの信頼性を想定していない可能性があり、したがって、TCPやUDPと、上で動作するように設計されたためです。 RTSP上MRCPを使用する場合したがって、MRCPサーバーから非同期イベントは、サーバ起動ANNOUNCEメソッド/応答通信に包装されています。サーバからクライアントへの非同期イベントを送信するために、将来のRTSP拡張機能は、サーバーから、このような非同期MRCPイベントを運ぶために別の車両を提供することになります。
An RTSP session is created when an RTSP SETUP message is sent from the client to a server and is addressed to a server URL or any one of its resource URLs without specifying a session-id. The server will establish a session context and will respond with a session-id to the client. This sequence will also set up the RTP transport parameters between the client and the server, and then the server will be ready to receive or send media streams. If the client wants to attach an additional resource to an existing session, the client should send that session's ID in the subsequent SETUP message.
RTSP SETUPメッセージがクライアントからサーバーに送信され、セッションIDを指定せずにサーバーのURLまたはそのリソースのURLのいずれかにアドレス指定されたときRTSPセッションが作成されます。サーバーは、セッションコンテキストを確立し、クライアントにセッションIDで応答します。この配列はまた、クライアントとサーバ間のRTPトランスポートパラメータを設定し、その後、サーバーは、メディアストリームを受信または送信できるようになります。クライアントは、既存のセッションに追加のリソースを添付したい場合、クライアントは、後続のSETUPメッセージにそのセッションのIDを送信する必要があります。
When a media server implementing MRCP over RTSP receives a PLAY, RECORD, or PAUSE RTSP method from an MRCP resource URL, it should respond with an RTSP 405 "Method not Allowed" response. For these resources, the only allowed RTSP methods are SETUP, TEARDOWN, DESCRIBE, and ANNOUNCE.
RTSP上でMRCPを実装するメディアサーバがMRCPリソースURLからPLAY、RECORD、またはPAUSE RTSPメソッドを受信すると、RTSP 405「メソッド許可されていません」応答で応答する必要があります。これらのリソースについては、のみ許可RTSP方法はSETUP、TEARDOWN、DESCRIBE、およびANNOUNCEです。
Example 1:
例1：
C->S: ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:4 Session:12345678 Content-Type:application/mrcp Content-Length:223
C-> S：RTSPを発表：4セッション：12345678のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：223 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
SPEAK 543257 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
<?xml version="1.0"?> <speak> <paragraph> <sentence>You have 4 new messages.</sentence> <sentence>The first is from <say-as type="name">Stephanie Williams</say-as> and arrived at <break/> <say-as type="time">3:45pm</say-as>.</sentence>
<？xml version = "1.0"？> <話す> <パラグラフ> <文>あなたは4件の新しいメッセージがあります。最初から</文> <文>は<言う-としてタイプ= "名前">ステファニー・ウィリアムズ</ >として-言うと<> <言う-ようなタイプ= "時間" />破る15:45 </言う-よう>に到着しました。</文>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C: RTSP/1.0 200 OK CSeq: 4 Session:12345678 RTP-Info:url=rtsp://media.server.com/media/synthesizer; seq=9810092;rtptime=3450012 Content-Type:application/mrcp Content-Length:52
S-> C：RTSP / 1.0 200 OKのCSeq：4セッション：12345678 RTP-情報：URL = RTSP：//media.server.com/media/synthesizer。 SEQ = 9810092; rtptime = 3450012コンテンツタイプ：アプリケーション/ MRCPのコンテンツ長：52
MRCP/1.0 543257 200 IN-PROGRESS
IN-PROGRESS MRCP / 1.0 543257 200
S->C: ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:6 Session:12345678
S-> C：RTSPを発表：6セッション：12345678 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
Content-Type:application/mrcp
Content-Length:123
SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0
SPEAK-COMPLETE 543257 COMPLETE MRCP / 1.0
C->S: RTSP/1.0 200 OK CSeq:6
C-> S：RTSP / 1.0 200 OKのCSeq：6
For the sake of brevity, most examples from here on show only the MRCP messages and do not show the RTSP message and headers in which they are tunneled. Also, RTSP messages such as response that are not carrying an MRCP message are also left out.
簡潔にするため、ショーのここからほとんどの例が唯一のMRCPメッセージとそれらがトンネル化されているRTSPメッセージとヘッダを表示されません。また、MRCPメッセージを搬送されないような応答としてRTSPメッセージも除外されます。
A single set of RTP/RTCP ports is negotiated and shared between the MRCP client and server when multiple media processing resources, such as automatic speech recognition (ASR) engines and text to speech (TTS) engines, are used for a single session. The individual resource instances allocated on the server under a common session identifier will feed from/to that single RTP stream.
RTP / RTCPポートの単一のセットは、ネゴシエートとMRCPクライアントと、音声の自動音声認識（ASR）エンジンおよびテキストなどの複数のメディア処理リソースは、（TTS）エンジンは、単一のセッションのために使用されるサーバの間で共有されます。共通のセッション識別子の下でサーバに割り当てられた個々のリソースインスタンスは、単一のRTPストリームへ/から供給されます。
The client can send multiple media streams towards the server, differentiated by using different synchronized source (SSRC) identifier values. Similarly the server can use multiple Synchronized Source (SSRC) identifier values to differentiate media streams originating from the individual transmission resource URLs if more than one exists. The individual resources may, on the other hand, work together to send just one stream to the client. This is up to the implementation of the media server.
クライアントは、別の同期ソース（SSRC）識別子の値を使用して区別サーバに向けて複数のメディアストリームを送信することができます。同様に、サーバは、2つ以上が存在する場合は、個々の送信リソースのURLから発信メディア・ストリームを区別するために、複数の同期ソース（SSRC）識別子の値を使用することができます。個々のリソースは、他の一方で、クライアントにただ一つのストリームを送信するために一緒に働くことがあります。これは、メディアサーバの実装次第です。
Since many of the definitions and syntax are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] refers to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [1]).
定義及び構文の多くは、HTTP / 1.1と同一であるので、本明細書は、彼らはそれをコピーするのではなく、定義されている部分を指します。簡潔にするため、[HX.Y]現在のHTTP / 1.1仕様（RFC 2616 [1]）のセクションX.Yを指します。
All the mechanisms specified in this document are described in both prose and an augmented Backus-Naur form (ABNF) similar to that used in [H2.1]. It is described in detail in RFC 4234 [3].
この文書で指定されたすべてのメカニズムが散文と[H2.1]で用いたものと同様の拡張バッカス・ナウアフォーム（ABNF）の両方に記載されています。これは、RFC 4234に詳細に記載されている[3]。
The ABNF provided along with the descriptive text is informative in nature and may not be complete. The complete message format in ABNF form is provided in Appendix A and is the normative format definition.
説明のテキストと共に提供ABNFは本質的に有益であると、完全ではないかもしれません。 ABNF形態の完全なメッセージフォーマットは、付録Aに設けられ、規範フォーマット定義です。
The MRCP PDU is textual using an ISO 10646 character set in the UTF-8 encoding (RFC 3629 [12]) to allow many different languages to be represented. However, to assist in compact representations, MRCP also allows other character sets such as ISO 8859-1 to be used when desired. The MRCP protocol headers and field names use only the US-ASCII subset of UTF-8. Internationalization only applies to certain fields like grammar, results, speech markup, etc., and not to MRCP as a whole.
MRCP PDUは、多くの異なる言語を表すことを可能にするUTF-8エンコーディング（RFC 3629 [12]）に設定されたISO 10646文字を使用してテキストです。しかしながら、コンパクトな表現を支援するために、MRCPはまた、所望の場合、このようなISO 8859-1のような他の文字セットを使用することを可能にします。 MRCPプロトコルヘッダおよびフィールド名はUTF-8の唯一のUS-ASCIIのサブセットを使用します。国際化は全体としてのみなど、文法、結果、音声マークアップ、などの特定のフィールドにはなく、MRCPに適用されます。
Lines are terminated by CRLF, but receivers SHOULD be prepared to also interpret CR and LF by themselves as line terminators. Also, some parameters in the PDU may contain binary data or a record spanning multiple lines. Such fields have a length value associated with the parameter, which indicates the number of octets immediately following the parameter.
行はCRLFで終了しているが、受信機は、ラインターミネータとして自分自身でCRとLFを解釈するために準備する必要があります。また、PDU内のいくつかのパラメータは、バイナリデータ、または複数の行にまたがるレコードを含んでいてもよいです。そのようなフィールドは、直ちにパラメータ次のオクテットの数を示すパラメータ、関連付けられた長さの値を有します。
The whole MRCP PDU is encoded in the body of the session level message as a MIME entity of type application/mrcp. The individual MRCP messages do not have addressing information regarding which resource the request/response are to/from. Instead, the MRCP message relies on the header of the session level message carrying it to deliver the request to the appropriate resource, or to figure out who the response or event is from.
全体MRCP PDUはタイプapplication / MRCPのMIMEエンティティとしてセッションレベルメッセージの本文に符号化されます。個々のMRCPメッセージは、要求/応答はへ/からであるリソースに関する情報をアドレス指定する必要はありません。代わりに、MRCPメッセージは適切なリソースに要求を配信するために、または応答またはイベントからある人を理解するためにそれを運ぶセッションレベルメッセージのヘッダに依存しています。
The MRCP message set consists of requests from the client to the server, responses from the server to the client and asynchronous events from the server to the client. All these messages consist of a start-line, one or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and an optional message body.
MRCPメッセージセットは、クライアントからサーバーへのリクエストで構成されて、クライアントとサーバーからクライアントへの非同期イベントへのサーバからの応答。すべてのこれらのメッセージは、スタートラインから成り、一つ以上のヘッダーフィールド（また、「ヘッダー」としても知られる）、空行（すなわち、CRLF前に何もない行）ヘッダフィールドの終わりを示す、および任意のメッセージ体。
generic-message = start-line
message-header
CRLF
[ message-body ]
message-body = *OCTET
メッセージボディ= * OCTET
start-line = request-line / status-line / event-line
スタートライン=リクエストライン/ステータスライン/イベントライン
The message-body contains resource-specific and message-specific data that needs to be carried between the client and server as a MIME entity. The information contained here and the actual MIME-types used to carry the data are specified later when addressing the specific messages.
メッセージボディには、リソース固有とMIMEエンティティとして、クライアントとサーバーの間で行われる必要があるメッセージ固有のデータが含まれています。情報はここに含まれていると、特定のメッセージの宛先を指定するときにデータを運ぶために使用される実際のMIME型は、後に指定されています。
If a message contains data in the message body, the header fields will contain content-headers indicating the MIME-type and encoding of the data in the message body.
メッセージは、メッセージ本文のデータが含まれている場合、ヘッダフィールドは、メッセージ本文のMIMEタイプとデータの符号化を示すコンテンツ・ヘッダを含むであろう。
An MRCP request consists of a Request line followed by zero or more parameters as part of the message headers and an optional message body containing data specific to the request message.
MRCP要求は、メッセージヘッダと要求メッセージに特定のデータを含む任意のメッセージ本体の一部としてゼロ以上のパラメータに続くリクエスト行から成ります。
The Request message from a client to the server includes, within the first line, the method to be applied, a method tag for that request, and the version of protocol in use.
クライアントからサーバへの要求メッセージは、最初の行の中に、この方法は、その要求のための方法タグ、および使用中のプロトコルのバージョンを適用することを含みます。
request-line = method-name SP request-id SP mrcp-version CRLF
リクエストライン=メソッド名SP要求-ID SPのMRCPバージョンCRLF
The request-id field is a unique identifier created by the client and sent to the server. The server resource should use this identifier in its response to this request. If the request does not complete with the response, future asynchronous events associated with this request MUST carry the request-id.
リクエスト-idフィールドは、クライアントによって作成され、サーバーに送信された一意の識別子です。サーバリソースは、この要求への応答では、この識別子を使用する必要があります。要求が応答を完了しない場合、この要求に関連した将来の非同期イベントは、リクエストIDを運ばなければなりません。
request-id = 1*DIGIT
リクエストID = 1 * DIGIT
The method-name field identifies the specific request that the client is making to the server. Each resource supports a certain list of requests or methods that can be issued to it, and will be addressed in later sections.
メソッド名のフィールドは、クライアントがサーバーになっている特定の要求を識別します。各リソースは、それに対して発行することができます要求または方法の特定のリストをサポートしており、後のセクションで対処します。
method-name = synthesizer-method / recognizer-method
メソッド名=シンセサイザー方式/認識装置、方法
The mrcp-version field is the MRCP protocol version that is being used by the client.
MRCP-バージョンフィールドは、クライアントによって使用されているMRCPプロトコルのバージョンです。
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
MRCPバージョン= "MRCP" "/" 1 * DIGIT "" 1 * DIGIT
After receiving and interpreting the request message, the server resource responds with an MRCP response message. It consists of a status line optionally followed by a message body.
要求メッセージを受信し、解釈した後、サーバリソースはMRCP応答メッセージで応答します。それは、必要に応じて、メッセージ本体に続くステータスラインで構成されています。
response-line = mrcp-version SP request-id SP status-code SP request-state CRLF
応答ライン= MRCPバージョンのSP要求-ID SPステータスコードSP要求状態CRLF
The mrcp-version field used here is similar to the one used in the Request Line and indicates the version of MRCP protocol running on the server.
ここで使用MRCP-versionフィールドは、要求ラインに使用されているものと同様であり、サーバ上で実行されているMRCPプロトコルのバージョンを示します。
The request-id used in the response MUST match the one sent in the corresponding request message.
反応に使用される要求IDは、対応する要求メッセージで送られたものと一致しなければなりません。
The status-code field is a 3-digit code representing the success or failure or other status of the request.
ステータスコードフィールドは、要求の成功または失敗、または他の状態を示す3桁のコードです。
The request-state field indicates if the job initiated by the Request is PENDING, IN-PROGRESS, or COMPLETE. The COMPLETE status means that the Request was processed to completion and that there will be no more events from that resource to the client with that request-id. The PENDING status means that the job has been placed on a queue and will be processed in first-in-first-out order. The IN-PROGRESS status means that the request is being processed and is not yet complete. A PENDING or IN-PROGRESS status indicates that further Event messages will be delivered with that request-id.
要求状態フィールドは、リクエストによって開始されたジョブが進行中、PENDING、または完了している場合を示しています。 COMPLETEのステータスは、要求が完了するまで処理されたことと、その要求-idを持つクライアントにそのリソースからこれ以上のイベントが存在することを意味します。保留状態は、ジョブがキューに配置されており、先入れ先出し順序で処理されることを意味します。 IN-PROGRESSのステータスは、要求が処理され、まだ完了していないされていることを意味します。保留中または進行中の状況はさらにイベントメッセージは、その要求-IDで配信されることを示しています。
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
要求状態= "COMPLETE" / "IN-PROGRESS" / "保留"
The status codes are classified under the Success(2XX) codes and the Failure(4XX) codes.
ステータスコードは成功（2XX）コードと失敗（4XX）コードの下に分類されています。
200 Success
201 Success with some optional parameters ignored.
401 Method not allowed
402 Method not valid in this state
403 Unsupported Parameter
404 Illegal Value for Parameter
405 Not found (e.g., Resource URI not initialized
or doesn't exist)
406 Mandatory Parameter Missing
407 Method or Operation Failed (e.g., Grammar compilation
failed in the recognizer. Detailed cause codes MAY BE
available through a resource specific header field.)
408 Unrecognized or unsupported message entity
409 Unsupported Parameter Value 421-499 Resource specific Failure codes
409のサポートされていないパラメータ値421から499リソースの特定の障害コード
The server resource may need to communicate a change in state or the occurrence of a certain event to the client. These messages are used when a request does not complete immediately and the response returns a status of PENDING or IN-PROGRESS. The intermediate results and events of the request are indicated to the client through the event message from the server. Events have the request-id of the request that is in progress and is generating these events and status value. The status value is COMPLETE if the request is done and this was the last event, else it is IN-PROGRESS.
サーバリソースは、状態の変化やクライアントへの特定のイベントの発生を通信する必要があるかもしれません。要求がすぐに完了しない場合にこれらのメッセージが使用され、応答がPENDINGのか、IN-PROGRESS状態を返します。要求の中間結果とイベントがサーバからのイベントメッセージを介してクライアントに示されています。イベントは進行中であり、これらのイベントとステータス値を生成しているリクエストのリクエストIDを持っています。要求が行われ、これが最後のイベントだったされている場合、ステータス値は、それが進行中で、それ以外COMPLETEです。
event-line = event-name SP request-id SP request-state SP mrcp-version CRLF
イベントライン=イベント名SP要求-IDのSP要求状態SPのMRCPバージョンCRLF
The mrcp-version used here is identical to the one used in the Request/Response Line and indicates the version of MRCP protocol running on the server.
ここで使用MRCPバージョン要求/応答ラインで使用したものと同一であり、サーバ上で実行されているMRCPプロトコルのバージョンを示します。
The request-id used in the event should match the one sent in the request that caused this event.
イベントに使用される要求IDは、このイベントを発生させ、要求で送られたものと一致しなければなりません。
The request-state indicates if the Request/Command causing this event is complete or still in progress, and is the same as the one mentioned in Section 5.2. The final event will contain a COMPLETE status indicating the completion of the request.
要求/コマンドならば、要求状態は、このイベントの原因を示す完全またはまだ進行中であり、5.2節で述べたものと同じです。最後のイベントは、要求の完了を示す完了ステータスを含むであろう。
The event-name identifies the nature of the event generated by the media resource. The set of valid event names are dependent on the resource generating it, and will be addressed in later sections.
イベント名は、メディアリソースによって生成されたイベントの性質を特定します。有効なイベント名のセットは、それを生成するリソースに依存しており、以降のセクションで対処します。
event-name = synthesizer-event / recognizer-event
イベント名=シンセサイザーイベント/認識器イベント
MRCP header fields, which include general-header (Section 5.4) and resource-specific-header (Sections 7.4 and 8.4), follow the same generic format as that given in Section 2.1 of RFC 2822 [7]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of linear whitespace (LWS), though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT.
一般的なヘッダを含むMRCPヘッダフィールド、（5.4）とリソース特有のヘッダ（セクション7.4および8.4）、RFC 2822のセクション2.1 [7]で与えられたものと同じ一般的なフォーマットに従います。フィールド値：各ヘッダフィールドは、コロン（「」）が続く名前で構成されています。フィールド名は大文字と小文字を区別しません。単一のSPが好ましいもののフィールド値は、線形空白（LWS）の任意の量によって先行されるかもしれません。ヘッダフィールドは、少なくとも1つのSPまたはHT各追加のラインを先行することによって、複数の行にわたって拡張することができます。
message-header = 1*(generic-header / resource-header)
メッセージヘッダー= 1 *（ジェネリックヘッダ/リソースヘッダ）
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.
異なるフィールド名を持つヘッダフィールドが受信される順序は重要ではありません。しかし、リクエストヘッダやレスポンスヘッダフィールドに続く最初の一般的なヘッダフィールドを、送信するために「お勧め」であり、エンティティヘッダフィールドで終わります。
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field value for that header field is defined as a comma-separated list (i.e., #(values)).
同じフィールド名を持つ複数のメッセージヘッダフィールドは、ヘッダフィールドの全フィールドの値がカンマ区切りリスト（すなわち、＃（値））として定義されている場合に限り、メッセージ中に存在してもよいです。
It MUST be possible to combine the multiple header fields into one "field-name:field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. Therefore, the order in which header fields with the same field-name are received is significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
カンマで区切られ、最初に後続の各フィールド値を追加することによって、メッセージのセマンティクスを変更することなく、「フィールド値のフィールド名」ペア1つに複数のヘッダフィールドを組み合わせることが可能でなければなりません。したがって、同じフィールド名を持つヘッダフィールドが受信される順序は、結合フィールド値の解釈に重要であり、メッセージが転送されるとき、したがって、プロキシは、これらのフィールドの値の順序を変更しないでください。
Generic Headers
ジェネリックヘッダ
generic-header = active-request-id-list / proxy-sync-id / content-id / content-type / content-length / content-base / content-location / content-encoding / cache-control / logging-tag
ジェネリックヘッダ=アクティブ要求IDリスト/プロキシシンクID /コンテンツID /コンテンツ・タイプ/コンテンツ長/コンテンツベース/コンテンツ位置/コンテンツ・エンコード/キャッシュ制御/ロギングタグ
All headers in MRCP will be case insensitive, consistent with HTTP and RTSP protocol header definitions.
MRCPのすべてのヘッダはHTTP及びRTSPプロトコルヘッダの定義と一致し、大文字と小文字を区別しないであろう。
In a request, this field indicates the list of request-ids to which it should apply. This is useful when there are multiple Requests that are PENDING or IN-PROGRESS and you want this request to apply to one or more of these specifically.
リクエストでは、このフィールドは、それが適用されるべき先の要求-IDのリストを示します。保留中または進行中のあなたは、この要求は、特にこれらの一つ以上に適用したいされている複数の要求がある場合に便利です。
In a response, this field returns the list of request-ids that the operation modified or were in progress or just completed. There could be one or more requests that returned a request-state of PENDING or IN-PROGRESS. When a method affecting one or more PENDING or IN-PROGRESS requests is sent from the client to the server, the response MUST contain the list of request-ids that were affected in this header field.
応答では、このフィールドは、操作が変更または進行中であったか、単に終了要求IDのリストを返します。保留中または進行中の要求の状態を返した1つまたは複数の要求があるかもしれません。一つ以上の保留中または進行中のリクエストに影響を与える方法は、クライアントからサーバに送信されると、応答がこのヘッダフィールドに影響を受けたリクエストIDのリストを含まなければなりません。
The active-request-id-list is only used in requests and responses, not in events.
アクティブ・リクエスト-ID-リストのみが要求と応答ではなく、イベントで使用されています。
For example, if a STOP request with no active-request-id-list is sent to a synthesizer resource (a wildcard STOP) that has one or more SPEAK requests in the PENDING or IN-PROGRESS state, all SPEAK requests MUST be cancelled, including the one IN-PROGRESS. In addition, the response to the STOP request would contain the request-id of all the SPEAK requests that were terminated in the active-request-id-list. In this case, no SPEAK-COMPLETE or RECOGNITION-COMPLETE events will be sent for these terminated requests.
アクティブな要求-IDリストと停止要求が係属中または進行中の状態の一つ以上のSPEAK要求を有するシンセサイザリソース（ワイルドカードSTOP）に送信される場合、例えば、全ての要求を話す、キャンセルしなければなりませんIN-PROGRESS 1を含みます。また、STOP要求に対する応答は、アクティブ要求-ID-listに終了されたすべてのSPEAK要求の要求IDを含んでいるでしょう。この場合、何のSPEAK-COMPLETEまたは認識COMPLETEイベントは、これらの終了要求に対して送信されません。
active-request-id-list = "Active-Request-Id-List" ":" request-id *("," request-id) CRLF
アクティブ・リクエスト-ID-リスト= "アクティブ要求-ID-リスト" "：" 要求-ID *（ "" リクエスト-ID）CRLF
When any server resource generates a barge-in-able event, it will generate a unique Tag and send it as a header field in an event to the client. The client then acts as a proxy to the server resource and sends a BARGE-IN-OCCURRED method (Section 7.10) to the synthesizer server resource with the Proxy-Sync-Id it received from the server resource. When the recognizer and synthesizer resources are part of the same session, they may choose to work together to achieve quicker interaction and response. Here, the proxy-sync-id helps the resource receiving the event, proxied by the client, to decide if this event has been processed through a direct interaction of the resources.
任意のサーバリソースがバージイン可能なイベントを生成するときに、固有のタグを生成し、クライアントにイベントのヘッダフィールドとして送信されます。その後、クライアントは、サーバリソースへのプロキシとして機能し、それがサーバリソースから受信したプロキシ同期-IDを持つシンセサイザー・サーバ・リソースへのBARGE-IN-OCCURRED方法（7.10）を送信します。認識装置とシンセサイザーのリソースが同じセッションの一部であるとき、彼らは迅速な相互作用や反応を達成するために協力することもできます。ここでは、プロキシ同期-IDは、このイベントは、リソースの直接的な相互作用を介して処理されているかどうかを判断するために、クライアントによってプロキシ、イベントを受け取るリソースに役立ちます。
proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF
プロキシ同期-ID = "プロキシ同期-ID" "：" 1 * ALPHA CRLF
See [H14.2]. This specifies the acceptable character set for entities returned in the response or events associated with this request. This is useful in specifying the character set to use in the Natural Language Semantics Markup Language (NLSML) results of a RECOGNITON-COMPLETE event.
[H14.2]を参照してください。これは、応答またはこの要求に関連するイベントで返されたエンティティのための許容可能な文字セットを指定します。これはRECOGNITON-COMPLETEイベントの自然言語意味論マークアップ言語（NLSML）の結果に使用する文字セットを指定する際に有用です。
See [H14.17]. Note that the content types suitable for MRCP are restricted to speech markup, grammar, recognition results, etc., and are specified later in this document. The multi-part content type "multi-part/mixed" is supported to communicate multiple of the above mentioned contents, in which case the body parts cannot contain any MRCP specific headers.
[H14.17]を参照してください。 MRCPに適したコンテンツの種類等の音声マークアップ、文法、認識結果に制限されており、この文書の後に指定されていることに注意してください。マルチパートコンテンツタイプ「マルチパート/混合」は、体の部分は、任意のMRCP特定のヘッダを含むことができない場合には、上述した内容の複数を通信するために支持されています。
This field contains an ID or name for the content, by which it can be referred to. The definition of this field conforms to RFC 2392 [14], RFC 2822 [7], RFC 2046 [13] and is needed in multi-part messages. In MRCP whenever the content needs to be stored, by either the client or the server, it is stored associated with this ID. Such content can be referenced during the session in URI form using the session:URI scheme described in a later section.
このフィールドは、それを参照することが可能なコンテンツのためのIDまたは名前が含まれています。このフィールドの定義は、RFC 2392 [14]、RFC 2822 [7] RFC 2046 [13]に準拠し、マルチパートメッセージに必要とされます。コンテンツは、クライアントまたはサーバのいずれかにより、格納する必要があるたびMRCPでは、このIDに関連付けられて保存されています。後のセクションで説明したURIスキーム：そのようなコンテンツは、セッションを使用してURI形式のセッション中に参照することができます。
The content-base entity-header field may be used to specify the base URI for resolving relative URLs within the entity.
コンテンツベースエンティティヘッダフィールドは、エンティティ内の相対URLを解決するためのベースURIを指定するために使用されてもよいです。
content-base = "Content-Base" ":" absoluteURI CRLF
コンテンツ・ベース=「コンテンツベース」「：」absoluteURIでCRLF
Note, however, that the base URI of the contents within the entity-body may be redefined within that entity-body. An example of this would be a multi-part MIME entity, which in turn can have multiple entities within it.
エンティティボディ内のコンテンツのベースURIは、そのエンティティボディ内に再定義することができることは、注意してください。この例は、順番に、その中に複数のエンティティを持つことができるマルチパートMIMEエンティティになります。
The content-encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content coding has been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the content-type header field. Content-encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
コンテンツコードエンティティヘッダフィールドはメディアタイプの修飾子として使用されます。存在する場合、その値は、追加のコンテンツ符号化復号化メカニズムはContent-Typeヘッダフィールドによって参照されるメディアタイプを得るために適用されなければならないもの、したがってエンティティボディに適用されているものを示しています。コンテンツのエンコーディングは、主に文書がその根底にあるメディアタイプのアイデンティティを失わずに圧縮することができるようにするために使用されます。
content-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
content-coding = token token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
コンテンツコーディング=トークントークン= 1 *（alphanum / " - " "" "！" / / / "％" / "*" / "_" / "+" / "`"/ "'"/"〜 "）
Content coding is defined in [H3.5]. An example of its use is
内容コーディングは[H3.5]で定義されています。その使用の例があります
Content-Encoding:gzip
コンテンツエンコード：gzipで
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.
複数のエンコーディングがエンティティに適用されている場合は、コンテンツのコーディングは、それらが適用された順にリストされなければなりません。
The content-location entity-header field MAY BE used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI.
コンテンツロケーションエンティティヘッダフィールドは、そのエンティティは、要求されたリソースのURIから離れた場所からアクセス可能である場合、メッセージで囲まれたエンティティのリソースの場所を供給するために使用されてもよいです。
content-location = "Content-Location" ":" ( absoluteURI / relativeURI ) CRLF
コンテンツの場所= "コンテンツロケーション" "："（absoluteURIで/ relativeURI）CRLF
The content-location value is a statement of the location of the resource corresponding to this particular entity at the time of the request. The media server MAY use this header field to optimize certain operations. When providing this header field, the entity being sent should not have been modified from what was retrieved from the content-location URI.
コンテンツロケーション値は、要求時にこの特定のエンティティに対応するリソースの位置のステートメントです。メディアサーバは、特定の操作を最適化するために、このヘッダフィールドを使用するかもしれません。このヘッダーフィールドを提供する場合、送信されるエンティティは、コンテンツロケーションURIから取得されたものから変更されていてはなりません。
For example, if the client provided a grammar markup inline, and it had previously retrieved it from a certain URI, that URI can be provided as part of the entity, using the content-location header field. This allows a resource like the recognizer to look into its cache to see if this grammar was previously retrieved, compiled, and cached. In which case, it might optimize by using the previously compiled grammar object.
例えば、クライアントは、文法マークアップをインラインで設けられ、それが以前にURIは、コンテンツロケーションヘッダーフィールドを使用して、エンティティの一部として提供することができ、特定のURIからそれを取得していました。これは、認識のようなリソースがこの文法は以前に、取り出されコンパイルされ、キャッシュされたかどうかを確認するためにそのキャッシュに検索することができます。その場合、それは以前にコンパイルされた文法オブジェクトを使用して最適化するかもしれません。
If the content-location is a relative URI, the relative URI is interpreted relative to the content-base URI.
コンテンツ位置が相対URIである場合、相対URIは、コンテンツベースURIに対して解釈されます。
This field contains the length of the content of the message body (i.e., after the double CRLF following the last header field). Unlike HTTP, it MUST be included in all messages that carry content beyond the header portion of the message. If it is missing, a default value of zero is assumed. It is interpreted according to [H14.13].
このフィールドは、（すなわち、最後のヘッダフィールドに続く二重CRLF後）メッセージ本文の内容の長さを含みます。 HTTPとは異なり、メッセージのヘッダ部分を越えてコンテンツを運ぶすべてのメッセージに含まれなければなりません。それが欠落している場合、デフォルト値のゼロが想定されます。これは[H14.13]に従って解釈されます。
If the media server plans on implementing caching, it MUST adhere to the cache correctness rules of HTTP 1.1 (RFC2616), when accessing and caching HTTP URI. In particular, the expires and cache-control headers of the cached URI or document must be honored and will always take precedence over the Cache-Control defaults set by this header field. The cache-control directives are used to define the default caching algorithms on the media server for the session or request. The scope of the directive is based on the method it is sent on. If the directives are sent on a SET-PARAMS method, it SHOULD apply for all requests for documents the media server may make in that session. If the directives are sent on any other messages, they MUST only apply to document requests the media server needs to make for that method. An empty cache-control header on the GET-PARAMS method is a request for the media server to return the current cache-control directives setting on the server.
キャッシュを実装上のメディアサーバープランの場合は、HTTP 1.1（RFC2616）、アクセスするとキャッシュHTTP URIのキャッシュ正しさのルールに従わなければなりません。具体的には、有効期限が切れると、キャッシュされたURIまたはドキュメントのキャッシュ制御ヘッダは尊重されなければならず、常にこのヘッダフィールドで設定されたのCache-Controlのデフォルト値よりも優先されます。キャッシュ制御ディレクティブは、セッションまたはリクエストのためのメディアサーバー上のデフォルトのキャッシングアルゴリズムを定義するために使用されています。ディレクティブのスコープは、それが送信された方法に基づいています。ディレクティブは、SET-PARAMSメソッドで送信されている場合は、メディアサーバーがそのセッションで行ったことがあり、文書のすべてのリクエストを申請してください。ディレクティブは、他のメッセージで送信されている場合、彼らは唯一のメディアサーバがそのメソッドのために作る必要がある要求を文書に適用する必要があります。 GET-PARAMS方法で空のキャッシュ制御ヘッダは、サーバ上の設定現在のキャッシュ制御ディレクティブを返すように、メディアサーバに対する要求です。
cache-control = "Cache-Control" ":" *WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )
CRLF
cache-directive = "max-age" "=" delta-seconds / "max-stale" "=" delta-seconds / "min-fresh" "=" delta-seconds
キャッシュ・ディレクティブ= "MAX-年齢" "=" デルタ秒/ "MAX-古い" "=" デルタ秒/ "MIN-新鮮" "=" デルタ - 秒
delta-seconds = 1*DIGIT
デルタ秒= 1 * DIGIT
Here, delta-seconds is a time value to be specified as an integer number of seconds, represented in decimal, after the time that the message response or data was received by the media server.
ここで、デルタ秒メッセージ応答又はデータは、メディアサーバによって受信された時刻の後、小数で表される秒の整数として指定する時間値です。
These directives allow the media server to override the basic expiration mechanism.
これらのディレクティブは、メディアサーバは、基本的な有効期限のメカニズムを無効にすることができます。
max-age
最大エージング
Indicates that the client is OK with the media server using a response whose age is no greater than the specified time in seconds. Unless a max-stale directive is also included, the client is not willing to accept the media server using a stale response.
クライアントは年齢秒で指定した時間よりも大きくない応答を使用して、メディアサーバとOKであることを示します。 MAX-古いディレクティブも含まれていない限り、クライアントは古くなったレスポンスを使用して、メディアサーバーを受け入れることを望んでいません。
min-fresh
放散します
Indicates that the client is willing to accept the media server using a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants the media server to use a response that will still be fresh for at least the specified number of seconds.
クライアントは新鮮生涯その現在の年齢プラス秒で指定された時間以上である応答を使用して、メディアサーバー受け入れる意志があることを示します。これは、クライアントがまだ秒の少なくとも指定された数のために新鮮になります応答を使用するようにメディアサーバーを望んでいる、です。
max-stale
MAX-古いです
Indicates that the client is willing to accept the media server using a response that has exceeded its expiration time. If max-stale is assigned a value, then the client is willing to accept the media server using a response that has exceeded its expiration time by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept the media server using a stale response of any age.
クライアントは、その有効期限を超過した応答を使用して、メディアサーバー受け入れる意志があることを示します。 MAX-古いに値が割り当てられている場合、クライアントは、指定された秒数を超えないことによって、その有効期限を超過した応答を使用して、メディアサーバーを受け入れて喜んでです。値がMAX-陳腐に割り当てられていない場合は、クライアントはすべての年齢の古い応答を使用して、メディアサーバーを受け入れて喜んでです。
The media server cache MAY BE requested to use stale response/data without validation, but only if this does not conflict with any "MUST"-level requirements concerning cache validation (e.g., a "must-revalidate" cache-control directive) in the HTTP 1.1 specification pertaining the URI.
メディア・サーバ・キャッシュは、検証されずに古い応答/データを使用することを要求されることがあり、これはキャッシュの検証（例えば、「MUST-再検証」キャッシュ制御ディレクティブ）に関する任意の「MUST」レベルの要件と競合しない場合にのみ、 URIを関連するHTTP 1.1仕様。
If both the MRCP cache-control directive and the cached entry on the media server include "max-age" directives, then the lesser of the two values is used for determining the freshness of the cached entry for that request.
MRCPキャッシュ制御ディレクティブおよびメディアサーバー上のキャッシュされたエントリの両方が「最大エージング」ディレクティブが含まれている場合、2つの値の小さい方がその要求のためにキャッシュされたエントリの鮮度を決定するために使用されます。
This header field MAY BE sent as part of a SET-PARAMS/GET-PARAMS method to set the logging tag for logs generated by the media server. Once set, the value persists until a new value is set or the session is ended. The MRCP server should provide a mechanism to subset its output logs so that system administrators can examine or extract only the log file portion during which the logging tag was set to a certain value.
このヘッダーフィールドは、メディアサーバーによって生成されるログのログタグを設定するには、Set-PARAMS / GET-PARAMS法の一部として送信することができます。一度設定すると、新しい値が設定されているか、またはセッションが終了するまで、値が持続します。 MRCPサーバーは、システム管理者が検査またはロギングタグは特定の値に設定された時にのみ、ログファイル部分を抽出することができるように、その出力ログをサブセットにメカニズムを提供しなければなりません。
MRCP clients using this feature should take care to ensure that no two clients specify the same logging tag. In the event that two clients specify the same logging tag, the effect on the MRCP server's output logs in undefined.
この機能を使用してMRCPクライアントには2つのクライアントが同じロギングタグを指定しないように注意する必要があります。 2つのクライアントは、未定義でMRCPサーバーの出力ログへの影響を同じロギングタグを指定した場合には。
logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF
ロギングタグ=「ロギングタグ」「：」1 * ALPHA CRLF
The capability of media server resources can be found using the RTSP DESCRIBE mechanism. When a client issues an RTSP DESCRIBE method for a media resource URI, the media server response MUST contain an SDP description in its body describing the capabilities of the media server resource. The SDP description MUST contain at a minimum the media header (m-line) describing the codec and other media related features it supports. It MAY contain another SDP header as well, but support for it is optional.
メディア・サーバ・リソースの機能は、RTSP機構をDESCRIBE使用して見つけることができます。クライアントは、RTSPは、メディアリソースURIのための方法を記載して発行すると、メディアサーバーの応答は、メディアサーバリソースの機能を説明、その本体でのSDP記述を含まなければなりません。 SDPの記述は最低限それがサポートするコーデックおよびその他のメディア関連の機能を説明するメディアヘッダ（M-ライン）を含まなければなりません。それだけでなく、別のSDPヘッダが含まれているかもしれないが、それのためのサポートはオプションです。
The usage of SDP messages in the RTSP message body and its application follows the SIP RFC 2543 [4], but is limited to media-related negotiation and description.
SDP RTSPメッセージ本体内のメッセージとそのアプリケーションの使用は、SIP RFC 2543に従う[4]が、メディア関連ネゴシエーションおよび説明に限定されます。
As discussed in Section 3.2, a client/server should share one RTSP session-id for the different resources it may use under the same session. The client MUST allocate a set of client RTP/RTCP ports for a new session and MUST NOT send a Session-ID in the SETUP message for the first resource. The server then creates a Session-ID and allocates a set of server RTP/RTCP ports and responds to the SETUP message.
3.2節で述べたように、クライアント/サーバーは、同じセッションで使用することができます別のリソースに対して1 RTSPセッションIDを共有する必要があります。クライアントは新しいセッションのためのクライアントRTP / RTCPポートのセットを割り当てる必要がありますし、最初のリソースのためのSETUPメッセージにセッションIDを送ってはいけません。サーバは、次に、セッションIDを作成し、サーバRTP / RTCPポートのセットを割り当て、SETUPメッセージに応答します。
If the client wants to open more resources with the same server under the same session, it will send the session-id (that it got in the earlier SETUP response) in the SETUP for the new resource. A SETUP message with an existing session-id tells the server that this new resource will feed from/into the same RTP/RTCP stream of that existing session.
クライアントが同じセッションで同じサーバーでより多くのリソースをオープンしたい場合は、新しいリソースのためのSETUPで（それは以前のSETUP応答になっていること）セッションIDを送信します。既存のセッションIDを持つSETUPメッセージは、この新しいリソースは、その既存のセッションの同じRTP / RTCPストリームに/からフィードするサーバーに指示します。
If the client wants to open a resource from a media server that is not where the first resource came from, it will send separate SETUP requests with no session-id header field in them. Each server will allocate its own session-id and return it in the response. Each of them will also come back with their own set of RTP/RTCP ports. This would be the case when the synthesizer engine and the recognition engine are on different servers.
クライアントが最初のリソースがどこから来たのではないメディアサーバーからのリソースをオープンしたい場合は、それはそれで無セッション-IDヘッダーフィールドを持つ別のSETUP要求を送信します。各サーバーは、独自のセッションIDを割り当て、それに応じてそれを返します。それらの各々はまた、RTP / RTCPポートの独自のセットで戻ってくるだろう。シンセサイザーエンジンと認識エンジンが異なるサーバ上にあるとき、これはケースになります。
The RTSP SETUP method SHOULD contain an SDP description of the media stream being set up. The RTSP SETUP response MUST contain an SDP description of the media stream that it expects to receive and send on that session.
RTSP設定方法は、設定されたメディアストリームのSDP記述を含むべきです。 RTSPのSETUP応答は、それが受信し、そのセッションに送信することを期待しているメディアストリームのSDP記述を含まなければなりません。
The SDP description in the SETUP method from the client SHOULD describe the required media parameters like codec, Named Signaling Event (NSE) payload types, etc. This could have multiple media headers (i.e., m-lines) to allow the client to provide the media server with more than one option to choose from.
クライアントからSETUP方法でSDP記述がコーデックのような必要なメディアパラメータを記述する必要があり、名前付きシグナリングイベント（NSE）ペイロードタイプ、等これは、クライアントが提供することができるように複数のメディアヘッダ（すなわち、Mライン）を有することができますから選択する複数のオプションを持つメディアサーバー。
The SDP description in the SETUP response should reflect the media parameters that the media server will be using for the stream. It should be within the choices that were specified in the SDP of the SETUP method, if one was provided.
SETUP応答のSDP記述は、メディアサーバがストリームのために使用されるメディアパラメータを反映する必要があります。これは、1つが提供された場合、セットアップ方法のSDPで指定された選択肢の範囲内であるべきです。
Example:
例：
C->S:
C-> S：
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0 CSeq:1 Transport:RTP/AVP;unicast;client_port=46456-46457 Content-Type:application/sdp Content-Length:190
SETUPのRTSP：//media.server.com/recognizer/ RTSP / 1.0のCSeq：1トランス：RTP / AVP;ユニキャスト; CLIENT_PORT = 46456から46457コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：190
v=0 o=- 123 456 IN IP4 10.0.0.1 s=Media Server p=+1-888-555-1212 c=IN IP4 0.0.0.0 t=0 0 m=audio 46456 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
V = 0 0 = - 123 456 IP4 IN 10.0.0.1 S =メディアサーバP = + 1-888-555-1212 C = IP4 0.0.0.0 IN T = 0、M =オーディオ46456 RTP / AVP 0 96 = rtpmap ：0 PCMU / 8000 = rtpmap：96電話イベント/ 8000 =のfmtp：96 0~15
S->C:
S-> C：
RTSP/1.0 200 OK CSeq:1 Session:0a030258_00003815_3bc4873a_0001_0000 Transport:RTP/AVP;unicast;client_port=46456-46457; server_port=46460-46461 Content-Length:190 Content-Type:application/sdp
RTSP / 1.0 200 OKのCSeq：1つのセッション：0a030258_00003815_3bc4873a_0001_0000トランスポート：RTP / AVP;ユニキャスト; CLIENT_PORT = 46456から46457; SERVER_PORT = 46460から46461のContent-Length：190のContent-Type：アプリケーション/ SDP
v=0 o=- 3211724219 3211724219 IN IP4 10.3.2.88 s=Media Server c=IN IP4 0.0.0.0 t=0 0 m=audio 46460 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
V = 0 0 = - 3211724219 3211724219 IN IP4 10.3.2.88のS =メディアサーバC = IP4 0.0.0.0 IN T = 0、M =オーディオ46460 RTP / AVP 0 96 = rtpmap：0 PCMU / 8000 = rtpmap：96 96 0-15：/ 8000 =のfmtp電話-イベント
If an SDP description was not provided in the RTSP SETUP method, then the media server may decide on parameters of the stream but MUST specify what it chooses in the SETUP response. An SDP announcement is only returned in a response to a SETUP message that does not specify a Session. That is, the server will not return an SDP announcement for the synthesizer SETUP of a session already established with a recognizer.
SDP記述がRTSPのSETUPメソッドで提供されていなかった場合は、メディアサーバは、ストリームのパラメータに決めることができるが、それはSETUP応答で選択した内容を指定しなければなりません。 SDP発表は唯一のセッションが指定されていないSETUPメッセージに応答して返されます。これは、サーバがすでに認識装置との間で確立したセッションのシンセサイザーのセットアップのためのSDPの発表を返しません、です。
C->S:
C-> S：
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0 CSeq:1 Transport:RTP/AVP;unicast;client_port=46498
SETUPのRTSP：//media.server.com/recognizer/ RTSP / 1.0のCSeq：1トランス：RTP / AVP;ユニキャスト; CLIENT_PORT = 46498
S->C:
S-> C：
RTSP/1.0 200 OK CSeq:1 Session:0a030258_000039dc_3bc48a13_0001_0000 Transport:RTP/AVP;unicast; client_port=46498; server_port=46502-46503 Content-Length:193 Content-Type:application/sdp
RTSP / 1.0 200 OKのCSeq：1つのセッション：0a030258_000039dc_3bc48a13_0001_0000トランスポート：RTP / AVP;ユニキャスト; CLIENT_PORT = 46498; SERVER_PORT = 46502から46503のContent-Length：193のContent-Type：アプリケーション/ SDP
v=0 o=- 3211724947 3211724947 IN IP4 10.3.2.88 s=Media Server c=IN IP4 0.0.0.0 t=0 0 m=audio 46502 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
V = 0 0 = - 3211724947 3211724947 IN IP4 10.3.2.88のS =メディアサーバC = IP4 0.0.0.0 IN T = 0、M =オーディオ46502 RTP / AVP 0 101 = rtpmap：0 PCMU / 8000 = rtpmap：101電話-イベント/ 8000 =のfmtp：101 0-15
This resource is capable of converting text provided by the client and generating a speech stream in real-time. Depending on the implementation and capability of this resource, the client can control parameters like voice characteristics, speaker speed, etc.
このリソースは、クライアントによって提供されたテキストを変換し、リアルタイムで音声ストリームを生成することができます。このリソースの実装と能力に応じて、クライアントは、音声特性、スピーカーの速度などのようなパラメータを制御することができます
The synthesizer resource is controlled by MRCP requests from the client. Similarly, the resource can respond to these requests or generate asynchronous events to the server to indicate certain conditions during the processing of the stream.
シンセサイザーのリソースは、クライアントからのMRCPの要求によって制御されています。同様に、リソースは、これらの要求に応えるか、ストリームの処理中に特定の条件を示すために、サーバへの非同期イベントを生成することができます。
The synthesizer maintains states because it needs to correlate MRCP requests from the client. The state transitions shown below describe the states of the synthesizer and reflect the request at the head of the queue. A SPEAK request in the PENDING state can be deleted or stopped by a STOP request and does not affect the state of the resource.
それは、クライアントからのMRCP要求を相関させる必要があるため、シンセサイザーは、状態を維持します。以下に示す状態遷移は、シンセサイザーの状態を説明し、キューの先頭に要求を反映しています。保留状態のSPEAK要求は、削除またはSTOP要求によって停止し、リソースの状態に影響を与えることはありませんすることができます。
Idle Speaking Paused
State State State
| | |
|----------SPEAK------->| |--------|
|<------STOP------------| CONTROL |
|<----SPEAK-COMPLETE----| |------->|
|<----BARGE-IN-OCCURRED-| |
| |--------| |
| CONTROL |-----------PAUSE--------->|
| |------->|<----------RESUME---------|
| | |----------|
| | PAUSE |
| | |--------->|
| |--------|----------| |
| BARGE-IN-OCCURRED | SPEECH-MARKER |
| |------->|<---------| |
|----------| | |------------|
| STOP | SPEAK |
| | | |----------->|
|<---------| |
|<-------------------STOP--------------------------|
The synthesizer supports the following methods.
シンセサイザは以下のメソッドをサポートしています。
synthesizer-method = "SET-PARAMS" / "GET-PARAMS" / "SPEAK" / "STOP" / "PAUSE" / "RESUME" / "BARGE-IN-OCCURRED" / "CONTROL"
シンセサイザー-方法は= "SET-PARAMSを" / "GET-PARAMS" / "SPEAK" / "STOP" / "PAUSE" / "RESUME" / "BARGE-IN-発生しました" / "CONTROL"
The synthesizer may generate the following events.
シンセサイザは、以下のイベントを生成することがあります。
synthesizer-event = "SPEECH-MARKER" / "SPEAK-COMPLETE"
シンセサイザー・イベント= "SPEECH-MARKER" / "SPEAK-COMPLETE"
A synthesizer message may contain header fields containing request options and information to augment the Request, Response, or Event of the message with which it is associated.
合成メッセージは、それが関連付けられているメッセージの要求、応答、またはイベントを増強するための要求オプションと情報を含むヘッダフィールドを含んでいてもよいです。
synthesizer-header = jump-target ; Section 7.4.1 / kill-on-barge-in ; Section 7.4.2 / speaker-profile ; Section 7.4.3 / completion-cause ; Section 7.4.4 / voice-parameter ; Section 7.4.5 / prosody-parameter ; Section 7.4.6 / vendor-specific ; Section 7.4.7 / speech-marker ; Section 7.4.8 / speech-language ; Section 7.4.9 / fetch-hint ; Section 7.4.10 / audio-fetch-hint ; Section 7.4.11 / fetch-timeout ; Section 7.4.12 / failed-uri ; Section 7.4.13 / failed-uri-cause ; Section 7.4.14 / speak-restart ; Section 7.4.15 / speak-length ; Section 7.4.16
シンセサイザヘッダー=ジャンプターゲット。 7.4.1 /殺すオンバージイン。 7.4.2 /スピーカープロファイル; 7.4.3 /完了原因。セクション7.4.4 /音声パラメータ; 7.4.5 /韻律パラメータ;ベンダー固有のセクション7.4.6 /。セクション7.4.7 /音声マーカー;セクション7.4.8 /音声言語。セクション7.4.9 /フェッチヒント;セクション7.4.10 /オーディオ・フェッチヒント;セクション7.4.11 /フェッチのタイムアウトを。セクション7.4.12 /失敗-URI;セクション7.4.13 /失敗-uriの原因;セクション7.4.14 /話す-再起動を。セクション7.4.15 /発言の長さ;セクション7.4.16
Parameter Support Methods/Events/Response
パラメータ・サポート・メソッド/イベント/レスポンス
jump-target MANDATORY SPEAK, CONTROL logging-tag MANDATORY SET-PARAMS, GET-PARAMS kill-on-barge-in MANDATORY SPEAK speaker-profile OPTIONAL SET-PARAMS, GET-PARAMS, SPEAK, CONTROL completion-cause MANDATORY SPEAK-COMPLETE voice-parameter MANDATORY SET-PARAMS, GET-PARAMS, SPEAK, CONTROL prosody-parameter MANDATORY SET-PARAMS, GET-PARAMS, SPEAK, CONTROL vendor-specific MANDATORY SET-PARAMS, GET-PARAMS speech-marker MANDATORY SPEECH-MARKER speech-language MANDATORY SET-PARAMS, GET-PARAMS, SPEAK fetch-hint MANDATORY SET-PARAMS, GET-PARAMS, SPEAK audio-fetch-hint MANDATORY SET-PARAMS, GET-PARAMS, SPEAK fetch-timeout MANDATORY SET-PARAMS, GET-PARAMS, SPEAK failed-uri MANDATORY Any failed-uri-cause MANDATORY Any speak-restart MANDATORY CONTROL speak-length MANDATORY SPEAK, CONTROL
ジャンプ・ターゲットMANDATORY SPEAK、CONTROLロギングタグMANDATORY SET - PARAMS、GET-PARAMS殺すオンバージインMANDATORY SPEAKスピーカープロファイルオプションSET-PARAMS、GET-PARAMS、SPEAK、CONTROL完了原因MANDATORY SPEAK-COMPLETE声-parameter MANDATORY SET - PARAMS、GET-PARAMS、SPEAK、CONTROL韻律パラメータMANDATORY SET - PARAMS、GET-PARAMS、SPEAK、CONTROLベンダー固有のMANDATORY SET-PARAMS、GET-PARAMSスピーチマーカーMANDATORY SPEECH - MARKER音声言語MANDATORY SET - PARAMSは、GET-PARAMSは、フェッチヒントを話すMANDATORY SET - PARAMS、GET-PARAMS、SPEAK MANDATORY SET - PARAMSは、GET-PARAMSは、フェッチ・タイムアウトMANDATORY SET - PARAMS、GET-PARAMSを話すオーディオ・フェッチヒント、失敗した-URI MANDATORYどれ失敗-uriの原因MANDATORYどれ発言再起動MANDATORY CONTROL発言長MANDATORY SPEAK、CONTROLを話します
This parameter MAY BE specified in a CONTROL method and controls the jump size to move forward or rewind backward on an active SPEAK request. A + or - indicates a relative value to what is being currently played. This MAY BE specified in a SPEAK request to indicate an offset into the speech markup that the SPEAK request should start speaking from. The different speech length units supported are dependent on the synthesizer implementation. If it does not support a unit or the operation, the resource SHOULD respond with a status code of 404 "Illegal or Unsupported value for parameter".
このパラメータは、CONTROLメソッドで指定し、前方に移動したり、アクティブなSPEAK要求に後方に巻き戻すジャンプの大きさを制御される可能性あり。 A +または - 現在再生されているものに対する相対値を示しています。これは、SPEAK要求から話し始めなければならない音声マークアップへのオフセットを示すために、SPEAK要求で指定することができます。サポートされているさまざまな音声の長さの単位は、シンセサイザーの実装に依存しています。それはユニットや操作をサポートしていない場合、リソースは、「パラメータに不正またはサポートされていない値」404のステータスコードで応答する必要があります。
jump-target = "Jump-Size" ":" speech-length-value CRLF speech-length-value = numeric-speech-length / text-speech-length text-speech-length = 1*ALPHA SP "Tag" numeric-speech-length= ("+" / "-") 1*DIGIT SP numeric-speech-unit numeric-speech-unit = "Second" / "Word" / "Sentence" / "Paragraph"
ジャンプ・ターゲット=「ジャンプ・サイズ」「：」発話長値CRLF音声長値=数値発話長/テキスト読み上げ長テキスト読み上げ長= 1 * ALPHA SP「タグ」numeric-スピーチ長=（「+」/「 - 」）1 * DIGITのSP数値音声素片数値音声単位=「秒」/「単語」/「センテンス」/「段落」
This parameter MAY BE sent as part of the SPEAK method to enable kill-on-barge-in support. If enabled, the SPEAK method is interrupted by DTMF input detected by a signal detector resource or by the start of speech sensed or recognized by the speech recognizer resource.
このパラメータは、キル・オン・バージ・インのサポートを有効にするにはSPEAK方法の一部として送信することができます。有効にした場合、SPEAK方法は、信号検出・リソースによって、または音声認識リソースによって感知または認識された音声の開始によって検出されたDTMF入力によって中断されています。
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF boolean-value = "true" / "false"
殺すオンバージイン=「「オンバージインを殺す」：」ブール値CRLFブール値=「真」/「偽」
If the recognizer or signal detector resource is on, the same server as the synthesizer, the server should be intelligent enough to recognize their interactions by their common RTSP session-id and work with each other to provide kill-on-barge-in support. The client needs to send a BARGE-IN-OCCURRED method to the synthesizer resource when it receives a barge-in-able event from the synthesizer resource or signal detector resource. These resources MAY BE local or distributed. If this field is not specified, the value defaults to "true".
認識器や信号検出器リソースがシンセサイザーと同じサーバー上にある場合、サーバは、それらの共通のRTSPセッションIDによってそれらの相互作用を認識し、キル・オン・バージ・インのサポートを提供するために、相互に動作するのに十分なインテリジェントでなければなりません。クライアントは、それがシンセサイザーのリソースや信号検出器リソースからバージイン可能なイベントを受信したときに、シンセサイザリソースにBARGE-IN-OCCURREDメソッドを送信する必要があります。これらのリソースは、ローカルまたは分散することができます。 「真」に、このフィールドが指定されていない場合、値がデフォルトになります。
This parameter MAY BE part of the SET-PARAMS/GET-PARAMS or SPEAK request from the client to the server and specifies the profile of the speaker by a URI, which may be a set of voice parameters like gender, accent, etc.
このパラメータは、SET-PARAMSの一部であってもよい/ - PARAMSをGETまたはクライアントからサーバへのリクエストを話し、URIにより、スピーカーのプロファイルを指定するなど、性別、アクセント、などの音声パラメータのセットとすることができます
speaker-profile = "Speaker-Profile" ":" uri CRLF
スピーカー・プロフィール=「スピーカー・プロフィール」「：」URI CRLF
This header field MUST be specified in a SPEAK-COMPLETE event coming from the synthesizer resource to the client. This indicates the reason behind the SPEAK request completion.
このヘッダーフィールドは、クライアントにシンセサイザーのリソースから来るSPEAK-COMPLETEイベントで指定する必要があります。これは、SPEAK要求の完了の背後にある理由を示します。
completion-cause = "Completion-Cause" ":" 1*DIGIT SP 1*ALPHA CRLF
完了-原因= "完了-原因" "：" 1 * DIGITのSP 1 * ALPHA CRLF
Cause-Code Cause-Name Description 000 normal SPEAK completed normally. 001 barge-in SPEAK request was terminated because of barge-in. 002 parse-failure SPEAK request terminated because of a failure to parse the speech markup text. 003 uri-failure SPEAK request terminated because, access to one of the URIs failed. 004 error SPEAK request terminated prematurely due to synthesizer error. 005 language-unsupported Language not supported.
原因コードが正常に終了説明000通常SPEAK-名前を原因。 001バージインSPEAK要求があるためバージインを終了しました。 002構文解析障害SPEAK要求があるため、音声マークアップテキストを解析に失敗し終了しました。 003 URI-障害SPEAK要求が原因で終了し、URIの1へのアクセスに失敗しました。 004エラーSPEAK要求が原因シンセサイザーエラーに途中で終了します。 005言語のサポートされていない言語がサポートされていません。
This set of parameters defines the voice of the speaker.
このパラメータセットは、話者の声を定義します。
voice-parameter = "Voice-" voice-param-name ":" voice-param-value CRLF
音声パラメータ= "Voice-" 音声のparam-名 "：" 音声のparam-値CRLF
voice-param-name is any one of the attribute names under the voice element specified in W3C's Speech Synthesis Markup Language Specification [9]. The voice-param-value is any one of the value choices of the corresponding voice element attribute specified in the above section.
音声のparam-nameは、W3Cの音声合成マークアップ言語仕様で指定された音声要素の下の属性名のいずれかである[9]。音声PARAM値は、上記のセクションで指定された対応する音声要素の属性の値の選択のいずれかです。
These header fields MAY BE sent in SET-PARAMS/GET-PARAMS request to define/get default values for the entire session or MAY BE sent in the SPEAK request to define default values for that speak request. Furthermore, these attributes can be part of the speech text marked up in Speech Synthesis Markup Language (SSML).
これらのヘッダフィールドは、/セッション全体のデフォルト値を取得したり、その発言要求のデフォルト値を定義するにはSPEAK要求で送信することができる定義するためのSET-PARAMS / GET-PARAMS要求で送信することができます。さらに、これらの属性は、音声合成マークアップ言語（SSML）でマークアップされた音声テキストの一部にすることができます。
These voice parameter header fields can also be sent in a CONTROL method to affect a SPEAK request in progress and change its behavior on the fly. If the synthesizer resource does not support this operation, it should respond back to the client with a status of unsupported.
これらの音声パラメータヘッダフィールドは、進行中のSPEAK要求に影響を与え、その場でその動作を変更するための制御方法で送信することができます。シンセサイザーのリソースがこの操作をサポートしていない場合、それはサポートされていない状況で、クライアントに応答する必要があります。
This set of parameters defines the prosody of the speech.
このパラメータセットは、音声の韻律を定義します。
prosody-parameter = "Prosody-" prosody-param-name ":" prosody-param-value CRLF
韻律パラメータ= "Prosody-" 韻律-PARAM名 "：" 韻律-PARAM値CRLF
prosody-param-name is any one of the attribute names under the prosody element specified in W3C's Speech Synthesis Markup Language Specification [9]. The prosody-param-value is any one of the value choices of the corresponding prosody element attribute specified in the above section.
韻律-のparam-nameは、W3Cの音声合成マークアップ言語仕様で指定された韻律要素の下の属性名のいずれかである[9]。韻律-PARAM値は、上記のセクションで指定された対応する韻律要素の属性の値の選択のいずれかです。
These header fields MAY BE sent in SET-PARAMS/GET-PARAMS request to define/get default values for the entire session or MAY BE sent in the SPEAK request to define default values for that speak request. Furthermore, these attributes can be part of the speech text marked up in SSML.
これらのヘッダフィールドは、/セッション全体のデフォルト値を取得したり、その発言要求のデフォルト値を定義するにはSPEAK要求で送信することができる定義するためのSET-PARAMS / GET-PARAMS要求で送信することができます。さらに、これらの属性は、SSMLでマークアップされた音声テキストの一部にすることができます。
The prosody parameter header fields in the SET-PARAMS or SPEAK request only apply if the speech data is of type text/plain and does not use a speech markup format.
SET-PARAMSにおける韻律パラメータヘッダフィールドまたは要求を話す音声データプレーンタイプtext /であり、音声マークアップ形式を使用していない場合にのみ適用されます。
These prosody parameter header fields MAY also be sent in a CONTROL method to affect a SPEAK request in progress and to change its behavior on the fly. If the synthesizer resource does not support this operation, it should respond back to the client with a status of unsupported.
これらの韻律パラメータヘッダフィールドも進行中のSPEAK要求に影響を与えるようにし、その場でその動作を変更するための制御方法で送信することができます。シンセサイザーのリソースがこの操作をサポートしていない場合、それはサポートされていない状況で、クライアントに応答する必要があります。
This set of headers allows for the client to set vendor-specific parameters.
ヘッダのこのセットは、ベンダー固有のパラメータを設定し、クライアントが可能になります。
vendor-specific = "Vendor-Specific-Parameters" ":" vendor-specific-av-pair *[";" vendor-specific-av-pair] CRLF
ベンダー固有= "ベンダー固有パラメータ" "：" ベンダー固有-AV対* [ ";"ベンダー固有-AVペア] CRLF
vendor-specific-av-pair = vendor-av-pair-name "=" vendor-av-pair-value
ベンダー特定のペア=ベンダーAVペア名「=」ベンダーによる対値
This header MAY BE sent in the SET-PARAMS/GET-PARAMS method and is used to set vendor-specific parameters on the server side. The vendor-av-pair-name can be any vendor-specific field name and conforms to the XML vendor-specific attribute naming convention. The vendor-av-pair-value is the value to set the attribute to and needs to be quoted.
このヘッダは、SET-PARAMS / GET-PARAMS方法で送られてもよいし、サーバ側のベンダー固有のパラメータを設定するために使用されています。ベンダーのAVペア名は、任意のベンダー固有のフィールド名であるとXMLベンダー固有の属性の命名規則に準拠することができます。ベンダーのAVペア値はに属性を設定するための値であり、引用符で囲む必要があります。
When asking the server to get the current value of these parameters, this header can be sent in the GET-PARAMS method with the list of vendor-specific attribute names to get separated by a semicolon.
これらのパラメータの現在の値を取得するには、サーバーを尋ねるときは、このヘッダは、セミコロンで区切って取得するために、ベンダー固有の属性名のリストとGET-PARAMSメソッドで送信することができます。
This header field contains a marker tag that may be embedded in the speech data. Most speech markup formats provide mechanisms to embed marker fields between speech texts. The synthesizer will generate SPEECH-MARKER events when it reaches these marker fields. This field SHOULD be part of the SPEECH-MARKER event and will contain the marker tag values.
このヘッダーフィールドは、音声データに埋め込まれてもよいマーカータグを含みます。ほとんどの音声マークアップ形式は、音声、テキスト間のマーカーフィールドを埋め込むためのメカニズムを提供します。それはこれらのマーカーフィールドに達したときにシンセサイザはSPEECH - MARKERイベントを生成します。このフィールドは、SPEECH - MARKERイベントの一部であるべきとマーカータグ値が含まれます。
speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF
音声マーカー=「スピーチマーカー」「：」1 * ALPHA CRLF
This header field specifies the default language of the speech data if it is not specified in the speech data. The value of this header field should follow RFC 3066 [16] for its values. This MAY occur in SPEAK, SET-PARAMS, or GET-PARAMS request.
それは音声データで指定されていない場合は、このヘッダフィールドは、音声データのデフォルト言語を指定します。このヘッダーフィールドの値は、その値の[16] RFC 3066に従うべきです。これは、SPEAKで発生するSET-PARAMSを、または要求-PARAMSを得ることができます。
speech-language = "Speech-Language" ":" 1*ALPHA CRLF
音声言語=「音声言語」「：」1 * ALPHA CRLF
When the synthesizer needs to fetch documents or other resources like speech markup or audio files, etc., this header field controls URI access properties. This defines when the synthesizer should retrieve content from the server. A value of "prefetch" indicates a file may be downloaded when the request is received, whereas "safe" indicates a file that should only be downloaded when actually needed. The default value is "prefetch". This header field MAY occur in SPEAK, SET-PARAMS, or GET-PARAMS requests.
シンセサイザーは、音声マークアップやオーディオファイルなどのような文書やその他のリソースを取得するために必要がある場合、このヘッダーフィールドはURIアクセスの特性を制御します。シンセサイザは、サーバからコンテンツを取得する必要があるとき、これが定義されています。 「プリフェッチ」の値は、要求を受信したときに、ファイルが「安全」のに対し、実際に必要な場合にのみダウンロードする必要があるファイルを示して、ダウンロードすることも示しています。デフォルト値は「プリフェッチ」です。このヘッダーフィールドは、SPEAKで発生するSET-PARAMSを、または要求-PARAMSのかもしれません。
fetch-hint = "Fetch-Hint" ":" 1*ALPHA CRLF
フェッチヒント=「フェッチヒント」を「：」1 * ALPHA CRLF
When the synthesizer needs to fetch documents or other resources like speech audio files, etc., this header field controls URI access properties. This defines whether or not the synthesizer can attempt to optimize speech by pre-fetching audio. The value is either "safe" to say that audio is only fetched when it is needed, never before; "prefetch" to permit, but not require the platform to pre-fetch the audio; or "stream" to allow it to stream the audio fetches. The default value is "prefetch". This header field MAY occur in SPEAK, SET-PARAMS, or GET-PARAMS requests.
シンセサイザーは、文書や音声、オーディオファイルなどのような他のリソースを取得する必要がある場合、このヘッダーフィールドはURIアクセスの特性を制御します。これは、シンセサイザがプリフェッチ音声により音声を最適化するように試みることができるかどうかを定義します。値は、それが決して前に、必要なときに音声が唯一のフェッチであることを言ってどちらかの「安全」です。オーディオをプリフェッチするためのプラットフォームを必要とする可能にするが、ないようにする「プリフェッチ」。それはオーディオフェッチをストリーミングできるようにするか、「ストリーム」。デフォルト値は「プリフェッチ」です。このヘッダーフィールドは、SPEAKで発生するSET-PARAMSを、または要求-PARAMSのかもしれません。
audio-fetch-hint = "Audio-Fetch-Hint" ":" 1*ALPHA CRLF
オーディオ・フェッチヒント=「オーディオ・フェッチヒント」「：」1 * ALPHA CRLF
When the synthesizer needs to fetch documents or other resources like speech audio files, etc., this header field controls URI access properties. This defines the synthesizer timeout for resources the media server may need to fetch from the network. This is specified in milliseconds. The default value is platform-dependent. This header field MAY occur in SPEAK, SET-PARAMS, or GET-PARAMS.
シンセサイザーは、文書や音声、オーディオファイルなどのような他のリソースを取得する必要がある場合、このヘッダーフィールドはURIアクセスの特性を制御します。これは、メディアサーバがネットワークからフェッチする必要があるかもしれないリソースのためのシンセサイザーのタイムアウトを定義します。これは、ミリ秒単位で指定します。デフォルト値は、プラットフォームに依存します。このヘッダーフィールドは、SPEAKで発生するSET-PARAMSを、または-PARAMSを得ることができます。
fetch-timeout = "Fetch-Timeout" ":" 1*DIGIT CRLF
フェッチ・タイムアウト=「「タイムアウトを取得」：」1 * DIGIT CRLF
When a synthesizer method needs a synthesizer to fetch or access a URI, and the access fails, the media server SHOULD provide the failed URI in this header field in the method response.
シンセサイザー方式がフェッチまたはURIにアクセスするためのシンセサイザーを必要とし、アクセスが失敗した場合、メディアサーバは、メソッドのレスポンスでこのヘッダフィールドに失敗したURIを提供する必要があります。
failed-uri = "Failed-URI" ":" Url CRLF
失敗した-URI = "失敗-URI" "：" URL CRLF
When a synthesizer method needs a synthesizer to fetch or access a URI, and the access fails, the media server SHOULD provide the URI specific or protocol-specific response code through this header field in the method response. This field has been defined as alphanumeric to accommodate all protocols, some of which might have a response string instead of a numeric response code.
合成方法は、フェッチまたはURIにアクセスするための合成を必要とし、アクセスが失敗した場合、メディアサーバは、メソッド応答のこのヘッダーフィールドを通してURI特異的またはプロトコル固有の応答コードを提供しなければなりません。このフィールドではなく、数値応答コードの応答文字列を持っているかもしれないいくつかのそれらのすべてのプロトコルを、対応するために、英数字として定義されています。
failed-uri-cause = "Failed-URI-Cause" ":" 1*ALPHA CRLF
= "失敗-URI-原因" "-uriの原因に失敗しました：" 1 * ALPHA CRLF
When a CONTROL jump backward request is issued to a currently speaking synthesizer resource and the jumps beyond the start of the speech, the current SPEAK request re-starts from the beginning of its speech data and the response to the CONTROL request would contain this header indicating a restart. This header MAY occur in the CONTROL response.
CONTROLジャンプ後方要求が発言の開始を超えて現在話しシンセサイザーリソースとジャンプに発行されると、その音声データの先頭から現在のSPEAK要求を再起動し、制御要求に対する応答が示すこのヘッダーが含まれます再起動。このヘッダは、制御応答に発生することがあります。
speak-restart = "Speak-Restart" ":" boolean-value CRLF
話す再始動=「スピーク・再起動」を「：」ブール値CRLF
This parameter MAY BE specified in a CONTROL method to control the length of speech to speak, relative to the current speaking point in the currently active SPEAK request. A "-" value is illegal in this field. If a field with a Tag unit is specified, then the media must speak until the tag is reached or the SPEAK request complete, whichever comes first. This MAY BE specified in a SPEAK request to indicate the length to speak in the speech data and is relative to the point in speech where the SPEAK request starts. The different speech length units supported are dependent on the synthesizer implementation. If it does not support a unit or the operation, the resource SHOULD respond with a status code of 404 "Illegal or Unsupported value for parameter".
このパラメータは、現在アクティブなSPEAK要求の現在のスピーキング点に対する、話すように音声の長さを制御するための制御方法で指定することができます。 A「 - 」の値は、この分野では違法です。タグ単位でのフィールドが指定されている場合は、タグに達するかのいずれか早い方の完全なSPEAK要求、されるまで、メディアが話さなければなりません。これは、音声データに話すように長さを示すために、SPEAK要求で指定し、SPEAK要求が開始演説の中でポイントを基準れるものであってもよいです。サポートされているさまざまな音声の長さの単位は、シンセサイザーの実装に依存しています。それはユニットや操作をサポートしていない場合、リソースは、「パラメータに不正またはサポートされていない値」404のステータスコードで応答する必要があります。
speak-length = "Speak-Length" ":" speech-length-value CRLF
話す長= "スピーク-Length" を "：" 発話長値CRLF
A synthesizer message may contain additional information associated with the Method, Response, or Event in its message body.
合成メッセージは、そのメッセージボディのメソッド、応答、またはイベントに関連する追加情報を含むことができます。
Marked-up text for the synthesizer to speak is specified as a MIME entity in the message body. The message to be spoken by the synthesizer can be specified inline (by embedding the data in the message body) or by reference (by providing the URI to the data). In either case, the data and the format used to markup the speech needs to be supported by the media server.
話をするシンセサイザーのためのマークアップテキストがメッセージ本文にMIMEエンティティとして指定されています。メッセージがシンセサイザによって話されるべきでは（データにURIを提供することによって）、または参照によって（メッセージ本体内のデータを埋め込むことにより）、インラインで指定することができます。いずれの場合においても、データと音声をマークアップするために使用されるフォーマットは、メディアサーバによってサポートされる必要があります。
All media servers MUST support plain text speech data and W3C's Speech Synthesis Markup Language [9] at a minimum and, hence, MUST support the MIME types text/plain and application/synthesis+ssml at a minimum.
すべてのメディアサーバーは、最低でも[9]プレーンテキストの音声データとW3Cの音声合成マークアップ言語をサポートしなければならないと、したがって、最低でもMIMEタイプtext / plainで、アプリケーション/合成+ SSMLをサポートしなければなりません。
If the speech data needs to be specified by URI reference, the MIME type text/uri-list is used to specify the one or more URIs that will list what needs to be spoken. If a list of speech URIs is specified, speech data provided by each URI must be spoken in the order in which the URI are specified.
音声データは、URI参照で指定する必要がある場合は、MIMEタイプtext / URI-リストが話される必要があるものをリストアップします一の以上のURIを指定するために使用されます。スピーチURIのリストが指定されている場合は、各URIによって提供された音声データは、URIが指定された順に話さなければなりません。
If the data to be spoken consists of a mix of URI and inline speech data, the multipart/mixed MIME-type is used and embedded with the MIME-blocks for text/uri-list, application/synthesis+ssml or text/plain. The character set and encoding used in the speech data may be specified according to standard MIME-type definitions. The multi-part MIME-block can contain actual audio data in .wav or Sun audio format. This is used when the client has audio clips that it may have recorded, then stored in memory or a local device, and that it currently needs to play as part of the SPEAK request. The audio MIME-parts can be sent by the client as part of the multi-part MIME-block. This audio will be referenced in the speech markup data that will be another part in the multi-part MIME-block according to the multipart/mixed MIME-type specification.
発話すべきデータがURIとインライン音声データの混在で構成されている場合、混合/マルチパートMIMEタイプを使用し、テキスト/ URIリスト、アプリケーション/合成+ SSML又はtext / plainのためのMIMEブロックが埋め込まれています。音声データに使用される文字セットと符号化は、標準的なMIMEタイプの定義に従って指定することができます。マルチパートMIME-ブロックは.WAVまたはSunオーディオ形式で実際のオーディオデータを含めることができます。これは、クライアントが、それは、メモリやローカルデバイスに保存され、記録され、それが現在SPEAK要求の一部として再生することが要求されている可能性があることをオーディオクリップがあった場合に使用されます。オーディオMIME-部分はマルチパートMIMEブロックの一部としてクライアントによって送信することができます。このオーディオは、混合/マルチパートMIME型の仕様に従ってマルチパートMIMEブロック内の他の一部となる音声マークアップ・データで参照されるであろう。
Example 1: Content-Type:text/uri-list Content-Length:176
例1：コンテンツタイプ：テキスト/ URIリストのContent-Length：176
http://www.cisco.com/ASR-Introduction.sml
http://www.cisco.com/ASR-Document-Part1.sml
http://www.cisco.com/ASR-Document-Part2.sml
http://www.cisco.com/ASR-Conclusion.sml
Example 2: Content-Type:application/synthesis+ssml Content-Length:104
実施例2：コンテンツタイプ：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<speak> <paragraph> <sentence>You have 4 new messages.</sentence> <sentence>The first is from <say-as type="name">Stephanie Williams</say-as> and arrived at <break/> <say-as type="time">3:45pm</say-as>.</sentence>
<話す> <パラグラフ> <文>あなたは4件の新しいメッセージがあります。最初から</文> <文>は<言う-としてタイプ=「名前」>ステファニー・ウィリアムズ</として-言う>と<休憩に到着/ > <言う-ようなタイプ= "時間"> 15:45 </言う-として>。</文>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
Example 3: Content-Type:multipart/mixed; boundary="--break"
例3：コンテンツタイプ：混合/マルチパート。境界=「 - ブレイク」
--break
Content-Type:text/uri-list
Content-Length:176
http://www.cisco.com/ASR-Introduction.sml http://www.cisco.com/ASR-Document-Part1.sml http://www.cisco.com/ASR-Document-Part2.sml http://www.cisco.com/ASR-Conclusion.sml
http://www.cisco.com/ASR-Introduction.sml http://www.cisco.com/ASR-Document-Part1.sml http://www.cisco.com/ASR-Document-Part2.sml http://www.cisco.com/ASR-Conclusion.sml
--break Content-Type:application/synthesis+ssml Content-Length:104
--breakのContent-Type：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?> <speak> <paragraph> <sentence>You have 4 new messages.</sentence> <sentence>The first is from <say-as type="name">Stephanie Williams</say-as> and arrived at <break/> <say-as type="time">3:45pm</say-as>.</sentence>
<？xml version = "1.0"？> <話す> <パラグラフ> <文>あなたは4件の新しいメッセージがあります。最初から</文> <文>は<言う-としてタイプ= "名前">ステファニー・ウィリアムズ</ >として-言うと<> <言う-ようなタイプ= "時間" />破る15:45 </言う-よう>に到着しました。</文>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak> --break
スキー旅行</韻律> </文> </パラグラフ> </話す> --break - <文>対象は、< "20％" 韻律率=>であります
The SET-PARAMS method, from the client to server, tells the synthesizer resource to define default synthesizer context parameters, like voice characteristics and prosody, etc. If the server accepted and set all parameters, it MUST return a Response-Status of 200. If it chose to ignore some optional parameters, it MUST return 201.
SET-PARAMS方法、クライアントからサーバーには、サーバーが受け入れられ、すべてのパラメータを設定した場合、それは200のレスポンス・ステータスを返さなければならないなど、音声特性と韻律のようなデフォルトのシンセサイザーのコンテキストパラメータを定義するシンセサイザーのリソースを伝えます。それはいくつかのオプションのパラメータを無視することを選択した場合、それは201を返さなければなりません。
If some of the parameters being set are unsupported or have illegal values, the server accepts and sets the remaining parameters and MUST respond with a Response-Status of 403 or 404, and MUST include in the response the header fields that could not be set.
設定されたパラメータの一部がサポートされていない、または不正な値を持っている場合、サーバは、受け付け、セット残りのパラメータを403または404の応答-状態で応答しなければならない、それに応答して設定することができなかったヘッダーフィールドを含まなければなりません。
Example: C->S:SET-PARAMS 543256 MRCP/1.0 Voice-gender:female Voice-category:adult Voice-variant:3
例：C-> S：SET-PARAMS 543256 MRCP / 1.0音声性別：女性の声 - カテゴリ：大人の声バリアント：3
S->C:MRCP/1.0 543256 200 COMPLETE
S-> C：MRCP / 1.0 543256 200 COMPLETE
The GET-PARAMS method, from the client to server, asks the synthesizer resource for its current synthesizer context parameters, like voice characteristics and prosody, etc. The client SHOULD send the list of parameters it wants to read from the server by listing a set of empty parameter header fields. If a specific list is not specified then the server SHOULD return all the settable parameters including vendor-specific parameters and their current values. The wild card use can be very intensive as the number of settable parameters can be large depending on the vendor. Hence, it is RECOMMENDED that the client does not use the wildcard GET-PARAMS operation very often.
GET-PARAMS方法、クライアントからサーバへ、音声特性と韻律のように、現在のシンセサイザーのコンテキストパラメータのためのシンセサイザーのリソースを要求するなど、クライアントがセットをリストすることで、サーバから読みたいパラメータのリストを送るべきです空のパラメータヘッダフィールド。特定のリストが指定されていない場合、サーバは、ベンダー固有のパラメータとその現在の値を含むすべての設定可能なパラメータを返すべきです。設定可能なパラメータの数は、ベンダーに依存して大きくすることができるようにワイルドカードの使用が非常に集中することができます。したがって、クライアントが非常に頻繁にワイルドカードGET-PARAMS操作を使用しないことが推奨されます。
Example: C->S:GET-PARAMS 543256 MRCP/1.0 Voice-gender: Voice-category: Voice-variant: Vendor-Specific-Parameters:com.mycorp.param1; com.mycorp.param2
例：C-> S：GET-PARAMS 543256 MRCP / 1.0音声性別：音声カテゴリ：声バリアント：ベンダー固有のパラメータ：com.mycorp.param1。 com.mycorp.param2
S->C:MRCP/1.0 543256 200 COMPLETE Voice-gender:female Voice-category:adult Voice-variant:3
S-> C：/ 1.0 MRCP 543256 200 COMPLETE音声性別：女性の声 - カテゴリ：大人の声バリアント：3
Vendor-Specific-Parameters:com.mycorp.param1="Company Name";
com.mycorp.param2="124324234@mycorp.com"
The SPEAK method from the client to the server provides the synthesizer resource with the speech text and initiates speech synthesis and streaming. The SPEAK method can carry voice and prosody header fields that define the behavior of the voice being synthesized, as well as the actual marked-up text to be spoken. If specific voice and prosody parameters are specified as part of the speech markup text, it will take precedence over the values specified in the header fields and those set using a previous SET-PARAMS request.
クライアントからサーバへのSPEAK方法は、音声、テキストとシンセサイザーのリソースを提供し、音声合成やストリーミングを開始します。 SPEAK方法は、音声および韻律ヘッダ合成される音声の挙動を定義するフィールドと同様に話されるべき実際のマークアップされたテキストを運ぶことができます。特定の音声および韻律パラメータは音声マークアップ・テキストの一部として指定されている場合、それはヘッダフィールドと、以前のSET-PARAMS要求を使用してこれらの組で指定された値よりも優先されます。
When applying voice parameters, there are 3 levels of scope. The highest precedence are those specified within the speech markup text, followed by those specified in the header fields of the SPEAK request and, hence, apply for that SPEAK request only, followed by the session default values that can be set using the SET-PARAMS request and apply for the whole session moving forward.
音声パラメータを適用する場合、範囲の3つのレベルがあります。最高の優先順位は、SET-PARAMSを使用して設定することができるセッションのデフォルト値が続くため、SPEAK要求のヘッダフィールドで指定されたものに続く音声マークアップテキスト、唯一そのSPEAK要求に適用内で指定されたものですセッション全体が前方に移動するための要求と適用されます。
If the resource is idle and the SPEAK request is being actively processed, the resource will respond with a success status code and a request-state of IN-PROGRESS.
リソースがアイドル状態で、SPEAK要求が活発に処理されている場合、リソースは、成功のステータスコードとIN-PROGRESSの要求状態で応答します。
If the resource is in the speaking or paused states (i.e., it is in the middle of processing a previous SPEAK request), the status returns success and a request-state of PENDING. This means that this SPEAK request is in queue and will be processed after the currently active SPEAK request is completed.
リソース（すなわち、それは以前SPEAK要求を処理中である）、話すまたは一時停止の状態にある場合、ステータスは、成功および保留中の要求の状態を返します。これは、このSPEAK要求がキュー内にあり、現在アクティブなSPEAK要求が完了した後に処理されることを意味します。
For the synthesizer resource, this is the only request that can return a request-state of IN-PROGRESS or PENDING. When the text to be synthesized is complete, the resource will issue a SPEAK-COMPLETE event with the request-id of the SPEAK message and a request-state of COMPLETE.
シンセサイザーのリソースについては、これは進行中または保留中の要求の状態を返すことができる唯一の要求です。合成すべきテキストが完了すると、リソースはSPEAKメッセージの要求-idとCOMPLETEの要求状態とSPEAK-COMPLETEイベントを発行します。
Example: C->S:SPEAK 543257 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
例：C-> S：ニュートラル音声カテゴリ：543257 MRCP / 1.0音声性別を話すティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543257 200
S->C:SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0 Completion-Cause:000 normal
S-> C：SPEAK-COMPLETE 543257 COMPLETE MRCP / 1.0完了原因：000正常
The STOP method from the client to the server tells the resource to stop speaking if it is speaking something.
クライアントからサーバーへのSTOPメソッドは、それが何かを話している場合は話して停止するようにリソースを伝えます。
The STOP request can be sent with an active-request-id-list header field to stop the zero or more specific SPEAK requests that may be in queue and return a response code of 200(Success). If no active-request-id-list header field is sent in the STOP request, it will terminate all outstanding SPEAK requests.
停止要求がキューにある200（成功）のレスポンスコードを返すことができるゼロ以上の特定のSPEAK要求を停止するアクティブ要求IDリストヘッダフィールドで送信することができます。アクティブな要求-IDリストヘッダフィールドはSTOP要求で送信されていない場合、それはすべての未SPEAK要求を終了します。
If a STOP request successfully terminated one or more PENDING or IN-PROGRESS SPEAK requests, then the response message body contains an active-request-id-list header field listing the SPEAK request-ids that were terminated. Otherwise, there will be no active-request-id-list header field in the response. No SPEAK-COMPLETE events will be sent for these terminated requests.
STOP要求が正常に要求を話す一つ以上のPENDINGを終了または進行中の場合は、応答メッセージ本体は終了しましたSPEAK要求-IDをリストしたアクティブ要求-ID-リストヘッダフィールドが含まれています。そうでない場合は、応答してアクティブな要求-IDリストヘッダフィールドが存在しないであろう。いいえSPEAK-COMPLETEイベントは、これらの終了要求に対して送信されません。
If a SPEAK request that was IN-PROGRESS and speaking was stopped, the next pending SPEAK request, if any, would become IN-PROGRESS and move to the speaking state.
IN-PROGRESSだったとSPEAK要求が停止したに言えば場合は、次の保留中のSPEAK要求があれば、IN-PROGRESSになると話すステートに移行します。
If a SPEAK request that was IN-PROGRESS and in the paused state was stopped, the next pending SPEAK request, if any, would become IN-PROGRESS and move to the paused state.
PROGRESS-INと一時停止状態にあったSPEAK要求が停止した場合は、次の保留中のSPEAK要求があれば、IN-PROGRESSになるだろうし、一時停止状態に移行します。
Example: C->S:SPEAK 543258 MRCP/1.0 Content-Type:application/synthesis+ssml Content-Length:104
例：C-> S：アプリケーション/合成+ SSMLのContent-Length：104 543258 MRCP / 1.0コンテンツタイプを話します
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543258 200
C->S:STOP 543259 200 MRCP/1.0
C-> S：STOP 543259 200 MRCP / 1.0
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543259 200 COMPLETEアクティブ要求-ID-リスト：543258
The BARGE-IN-OCCURRED method is a mechanism for the client to communicate a barge-in-able event it detects to the speech resource.
BARGE-IN-OCCURRED方法は、それが音声リソースを検出しバージイン可能なイベントを通信するためのクライアントのためのメカニズムです。
This event is useful in two scenarios,
このイベントは、2つのシナリオで有用です
1. The client has detected some events like DTMF digits or other barge-in-able events and wants to communicate that to the synthesizer.
1.クライアントは、DTMF数字や他のバージイン可能なイベントのようないくつかのイベントを検出し、シンセサイザにそれを通信したいました。
2. The recognizer resource and the synthesizer resource are in different servers. In which case the client MUST act as a Proxy and receive event from the recognition resource, and then send a BARGE-IN-OCCURRED method to the synthesizer. In such cases, the BARGE-IN-OCCURRED method would also have a proxy-sync-id header field received from the resource generating the original event.
2.認識器リソースとシンセサイザーのリソースが異なるサーバです。その場合、クライアントはプロキシとして動作しなければならないと認識リソースからイベントを受信した後、シンセサイザにBARGE-IN-OCCURRED方法を送信します。このような場合に、バージイン-OCCURRED方法はまた、プロキシ同期-IDヘッダフィールドは、元のイベントを生成するリソースから受け取ったであろう。
If a SPEAK request is active with kill-on-barge-in enabled, and the BARGE-IN-OCCURRED event is received, the synthesizer should stop streaming out audio. It should also terminate any speech requests queued behind the current active one, irrespective of whether they have barge-in enabled or not. If a barge-in-able prompt was playing and it was terminated, the response MUST contain the request-ids of all SPEAK requests that were terminated in its active-request-id-list. There will be no SPEAK-COMPLETE events generated for these requests.
SPEAK要求はキル・オン・はしけのあるアクティブ有効になっている、とBARGE-IN-発生したイベントを受信した場合、シンセサイザー、オーディオをストリーミングを停止する必要があります。また、関係なく、彼らが有効になってバージインを持っているかどうかの、現在アクティブな1の後ろにキューに入れられた任意の音声要求を終了する必要があります。バージイン可能なプロンプトが遊んでいたし、それが終了した場合は、すべてがそのアクティブ・リクエスト-ID-listに終了された要求を話すのは、応答が要求-idを含まなければなりません。これらの要求のために生成された無SPEAK-COMPLETEイベントはありません。
If the synthesizer and the recognizer are on the same server, they could be optimized for a quicker kill-on-barge-in response by having them interact directly based on a common RTSP session-id. In these cases, the client MUST still proxy the recognition event through a BARGE-IN-OCCURRED method, but the synthesizer resource may have already stopped and sent a SPEAK-COMPLETE event with a barge-in completion cause code. If there were no SPEAK requests terminated as a result of the BARGE-IN-OCCURRED method, the response would still be a 200 success, but MUST not contain an active-request-id-list header field.
シンセサイザーと認識装置は、同じサーバー上にある場合、それらは迅速キル・オン・バージイン応答、それらが共通のRTSPセッション-IDに基づいて直接対話持つことによってのために最適化することができます。これらのケースでは、クライアントはプロキシがBARGE-IN-OCCURRED法による認識事象が、すでに持っているかもしれシンセサイザーのリソースは停止しなければならないと完了バージイン原因コードとSPEAK-COMPLETEイベントを送りました。 BARGE-IN-OCCURREDメソッドの結果として終了全くSPEAK要求がなかった場合は、応答はまだ200個の成功するだろうが、アクティブ要求-ID-リストヘッダフィールドを含めることはできません。
C->S:SPEAK 543258 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
C-> S：ニュートラル音声カテゴリ：ティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104 543258 MRCP / 1.0音声性別を話します
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543258 200
C->S:BARGE-IN-OCCURRED 543259 200 MRCP/1.0 Proxy-Sync-Id:987654321
C-> S：BARGE-IN-OCCURRED 543259 200 MRCP / 1.0プロキシ同期-ID：987654321
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543259 200 COMPLETEアクティブ要求-ID-リスト：543258
The PAUSE method from the client to the server tells the resource to pause speech, if it is speaking something. If a PAUSE method is issued on a session when a SPEAK is not active, the server SHOULD respond with a status of 402 or "Method not valid in this state". If a PAUSE method is issued on a session when a SPEAK is active and paused, the server SHOULD respond with a status of 200 or "Success". If a SPEAK request was active, the server MUST return an active-request-id-list header with the request-id of the SPEAK request that was paused.
クライアントからサーバへのPAUSE方法は、それが何かを話している場合は、スピーチを一時停止するリソースを伝えます。 SPEAKがアクティブでないとき、PAUSEメソッドがセッションに発行された場合、サーバは402のステータスまたは「この状態のメソッド有効ではありません」と応答する必要があります。 PAUSEメソッドはSPEAKがアクティブなときに、セッションで発行し、一時停止している場合、サーバは200のステータスまたは「成功」と応答する必要があります。 SPEAK要求がアクティブであった場合、サーバは一時停止されたSPEAK要求の要求IDとアクティブ要求IDリストヘッダを返さなければなりません。
C->S:SPEAK 543258 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
C-> S：ニュートラル音声カテゴリ：ティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104 543258 MRCP / 1.0音声性別を話します
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543258 200
C->S:PAUSE 543259 MRCP/1.0
C-> S：PAUSE 543259 MRCP / 1.0
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543259 200 COMPLETEアクティブ要求-ID-リスト：543258
The RESUME method from the client to the server tells a paused synthesizer resource to continue speaking. If a RESUME method is issued on a session when a SPEAK is not active, the server SHOULD respond with a status of 402 or "Method not valid in this state". If a RESUME method is issued on a session when a SPEAK is active and speaking (i.e., not paused), the server SHOULD respond with a status of 200 or "Success". If a SPEAK request was active, the server MUST return an active-request-id-list header with the request-id of the SPEAK request that was resumed
クライアントからサーバへのRESUME方法は話す続けるために一時停止したシンセサイザーのリソースを伝えます。 SPEAKがアクティブでないときにresumeメソッドは、セッションで発行された場合、サーバは402のステータスまたは「この状態のメソッド有効ではありません」と応答する必要があります。 SPEAKがアクティブと話すときにRESUME方法は（すなわち、一時停止していない）セッションで発行された場合、サーバは200のステータスまたは「成功」と応答する必要があります。 SPEAK要求がアクティブであった場合、サーバを再開したSPEAK要求の要求IDとアクティブ要求IDリストヘッダを返さなければなりません
Example: C->S:SPEAK 543258 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
例：C-> S：ニュートラル音声カテゴリ：543258 MRCP / 1.0音声性別を話すティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543258 200
C->S:PAUSE 543259 MRCP/1.0
C-> S：PAUSE 543259 MRCP / 1.0
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543259 200 COMPLETEアクティブ要求-ID-リスト：543258
C->S:RESUME 543260 MRCP/1.0
C-> S：RESUME 543260 MRCP / 1.0
S->C:MRCP/1.0 543260 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543260 200 COMPLETEアクティブ要求-ID-リスト：543258
The CONTROL method from the client to the server tells a synthesizer that is speaking to modify what it is speaking on the fly. This method is used to make the synthesizer jump forward or backward in what it is being spoken, change speaker rate and speaker parameters, etc. It affects the active or IN-PROGRESS SPEAK request. Depending on the implementation and capability of the synthesizer resource, it may allow this operation or one or more of its parameters.
クライアントからサーバーへの制御方法は、それがその場で話しているものを修正するために話しているシンセサイザーを伝えます。この方法は、それがアクティブまたは進行中の影響など、前方または後方にそれが話されているものでシンセサイザーをジャンプさせるスピーカー率とスピーカーのパラメータを変更するために使用されたリクエストを話します。シンセサイザーリソースの実装と能力に応じて、この操作やそのパラメータの一つ以上を可能にすることができます。
When a CONTROL to jump forward is issued and the operation goes beyond the end of the active SPEAK method's text, the request succeeds. A SPEAK-COMPLETE event follows the response to the CONTROL method. If there are more SPEAK requests in the queue, the synthesizer resource will continue to process the next SPEAK method. When a CONTROL to jump backwards is issued and the operation jumps to the beginning of the speech data of the active SPEAK request, the response to the CONTROL request contains the speak-restart header.
前方にジャンプするCONTROLが発行され、操作がアクティブなSPEAK方式のテキストの終わりを超えている場合、要求は成功します。 SPEAK-COMPLETEイベントは、CONTROLメソッドへの応答に従います。より多くのSPEAK要求がキューにある場合は、シンセサイザーのリソースは、次のSPEAK方法を処理していきます。後方ジャンプするCONTROLが発行され、操作がアクティブなSPEAK要求の音声データの先頭にジャンプした場合、制御要求に対する応答は発言リスタートヘッダが含まれています。
These two behaviors can be used to rewind or fast-forward across multiple speech requests, if the client wants to break up a speech markup text into multiple SPEAK requests.
クライアントが複数のSPEAK要求に音声マークアップテキストを分割したい場合は、これらの2つの動作は、複数の音声要求間で巻き戻しや早送りすることができます。
If a SPEAK request was active when the CONTROL method was received, the server MUST return an active-request-id-list header with the Request-id of the SPEAK request that was active.
制御方法を受信したときにSPEAK要求がアクティブであった場合、サーバは、アクティブであったSPEAK要求の要求-IDとアクティブ要求IDリストヘッダを返さなければなりません。
Example: C->S:SPEAK 543258 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
例：C-> S：ニュートラル音声カテゴリ：543258 MRCP / 1.0音声性別を話すティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543258 200
C->S:CONTROL 543259 MRCP/1.0 Prosody-rate:fast
C-> S：CONTROL 543259 MRCP / 1.0韻律レート：速いです
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543259 200 COMPLETEアクティブ要求-ID-リスト：543258
C->S:CONTROL 543260 MRCP/1.0
C-> S：CONTROL 543260 MRCP / 1.0
Jump-Size:-15 Words
ジャンプ-サイズ：-15言葉
S->C:MRCP/1.0 543260 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP / 1.0 543260 200 COMPLETEアクティブ要求-ID-リスト：543258
This is an Event message from the synthesizer resource to the client indicating that the SPEAK request was completed. The request-id header field WILL match the request-id of the SPEAK request that initiated the speech that just completed. The request-state field should be COMPLETE indicating that this is the last Event with that request-id, and that the request with that request-id is now complete. The completion-cause header field specifies the cause code pertaining to the status and reason of request completion such as the SPEAK completed normally or because of an error or kill-on-barge-in, etc.
これは、SPEAK要求が完了したことを示すシンセサイザーリソースからクライアントへのイベントメッセージです。リクエスト-IDヘッダーフィールドは、完了したばかりのスピーチを開始したSPEAK要求の要求-IDと一致します。要求状態のフィールドは、これは、その要求-idを持つ最後のイベントであること、そしてその要求-idの要求が完了しましたことを示すCOMPLETEする必要があります。完了原因ヘッダフィールドは、正常終了またはエラーのため、または殺すオンバージイン、等SPEAKなどの要求の完了の状態および理由に関連する原因コードを指定します
Example: C->S:SPEAK 543260 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
例：C-> S：ニュートラル音声カテゴリ：543260 MRCP / 1.0音声性別を話すティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:MRCP/1.0 543260 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543260 200
S->C:SPEAK-COMPLETE 543260 COMPLETE MRCP/1.0
S-> C：SPEAK-COMPLETE 543260 COMPLETE MRCP / 1.0
Completion-Cause:000 normal
完成-原因：通常000
This is an event generated by the synthesizer resource to the client when it hits a marker tag in the speech markup it is currently processing. The request-id field in the header matches the SPEAK request request-id that initiated the speech. The request-state field should be IN-PROGRESS as the speech is still not complete and there is more to be spoken. The actual speech marker tag hit, describing where the synthesizer is in the speech markup, is returned in the speech-marker header field.
これは、それが現在処理している音声マークアップでマーカータグを打つときに、クライアントへのシンセサイザーリソースによって生成されたイベントです。ヘッダ内の要求IDフィールドはスピーチを開始したSPEAK要求の要求IDと一致します。音声はまだ完了していないと話さがよりがあるとして、要求状態フィールドが進行中である必要があります。シンセサイザは、音声マークアップである場合について説明する実際の音声マーカータグヒットは、音声マーカーヘッダフィールドに戻されます。
Example: C->S:SPEAK 543261 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
例：C-> S：ニュートラル音声カテゴリ：543261 MRCP / 1.0音声性別を話すティーンエイジャーの韻律-音量：中のContent-Type：アプリケーション/合成+ SSMLのContent-Length：104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<mark name="here"/>
<sentence>The subject is
<prosody rate="-20%">ski trip</prosody>
</sentence>
<mark name="ANSWER"/>
</paragraph>
</speak>
S->C:MRCP/1.0 543261 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543261 200
S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0 Speech-Marker:here
S-> C：SPEECH-MARKER 543261 IN-PROGRESS MRCP / 1.0スピーチ-マーカー：ここ
S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0 Speech-Marker:ANSWER
S-> C：SPEECH-MARKER 543261 IN-PROGRESS MRCP / 1.0スピーチ-マーカー：ANSWER
S->C:SPEAK-COMPLETE 543261 COMPLETE MRCP/1.0 Completion-Cause:000 normal
S-> C：SPEAK-COMPLETE 543261 COMPLETE MRCP / 1.0完了原因：000正常
The speech recognizer resource is capable of receiving an incoming voice stream and providing the client with an interpretation of what was spoken in textual form.
音声認識リソースが着信音声ストリームを受信し、テキスト形式で話された内容の解釈をクライアントに提供することが可能です。
The recognizer resource is controlled by MRCP requests from the client. Similarly, the resource can respond to these requests or generate asynchronous events to the server to indicate certain conditions during the processing of the stream. Hence, the recognizer maintains states to correlate MRCP requests from the client. The state transitions are described below.
認識器リソースは、クライアントからのMRCPの要求によって制御されています。同様に、リソースは、これらの要求に応えるか、ストリームの処理中に特定の条件を示すために、サーバへの非同期イベントを生成することができます。したがって、認識装置は、クライアントからのMRCP要求を相関させる状態を維持します。状態遷移は、以下に記載されています。
Idle Recognizing Recognized
State State State
| | |
|---------RECOGNIZE---->|---RECOGNITION-COMPLETE-->|
|<------STOP------------|<-----RECOGNIZE-----------|
| | |
| | |-----------|
| |--------| GET-RESULT |
| START-OF-SPEECH | |---------->|
|------------| |------->| |
| | |----------| |
| DEFINE-GRAMMAR | RECOGNITION-START-TIMERS |
|<-----------| |<---------| |
| | |
| | |
|-------| | |
| STOP | |
|<------| | |
| |
|<-------------------STOP--------------------------|
|<-------------------DEFINE-GRAMMAR----------------|
The recognizer supports the following methods. recognizer-method = SET-PARAMS / GET-PARAMS / DEFINE-GRAMMAR / RECOGNIZE / GET-RESULT / RECOGNITION-START-TIMERS / STOP
認識装置は、以下のメソッドをサポートしています。認識法= SET-PARAMS / GET-PARAMS / DEFINE-文法/ RECOGNIZE / GET-RESULT /認識STARTタイマー/ STOP
The recognizer may generate the following events.
認識装置は、以下のイベントを生成することがあります。
recognizer-event = START-OF-SPEECH / RECOGNITION-COMPLETE
認識イベント= START-OF-SPEECH /認識COMPLETE
A recognizer message may contain header fields containing request options and information to augment the Method, Response, or Event message it is associated with.
認識メッセージは、それが関連付けられているメソッド、応答、またはイベントメッセージを増強するための要求オプションと情報を含むヘッダフィールドを含んでいてもよいです。
recognizer-header = confidence-threshold ; Section 8.4.1 / sensitivity-level ; Section 8.4.2 / speed-vs-accuracy ; Section 8.4.3 / n-best-list-length ; Section 8.4.4 / no-input-timeout ; Section 8.4.5 / recognition-timeout ; Section 8.4.6 / waveform-url ; Section 8.4.7 / completion-cause ; Section 8.4.8 / recognizer-context-block ; Section 8.4.9 / recognizer-start-timers ; Section 8.4.10 / vendor-specific ; Section 8.4.11 / speech-complete-timeout ; Section 8.4.12 / speech-incomplete-timeout; Section 8.4.13 / dtmf-interdigit-timeout ; Section 8.4.14 / dtmf-term-timeout ; Section 8.4.15 / dtmf-term-char ; Section 8.4.16 / fetch-timeout ; Section 8.4.17 / failed-uri ; Section 8.4.18 / failed-uri-cause ; Section 8.4.19 / save-waveform ; Section 8.4.20 / new-audio-channel ; Section 8.4.21 / speech-language ; Section 8.4.22
認識ヘッダー=信頼しきい値;セクション8.4.1 /感度レベル。セクション8.4.2 /速度対精度。 8.4.3 / nベストリストの長さ;セクション8.4.4 /無入力タイムアウト。セクション8.4.5 /認識タイムアウト。セクション8.4.6 /波形URL;セクション8.4.7 /完了原因。セクション8.4.8 /レコグナイザコンテキストブロック。セクション8.4.9 /認識エンジンスタートタイマー。セクション8.4.10 /ベンダー固有;セクション8.4.11 /音声の完全なタイムアウト。セクション8.4.12 /音声不完全タイムアウト。セクション8.4.13 / DTMF-桁間タイムアウト。セクション8.4.14 / DTMF-用語タイムアウト。セクション8.4.15 / DTMF-用語-CHAR。セクション8.4.16 /フェッチのタイムアウトを。セクション8.4.17 /失敗-URI;セクション8.4.18 /失敗-uriの原因;セクション8.4.19 /セーブ-波形を、セクション8.4.20 /新しいオーディオチャンネル。セクション8.4.21 /音声言語。セクション8.4.22
Parameter Support Methods/Events
パラメータ・サポート・メソッド/イベント
confidence-threshold MANDATORY SET-PARAMS, RECOGNIZE GET-RESULT sensitivity-level Optional SET-PARAMS, GET-PARAMS, RECOGNIZE speed-vs-accuracy Optional SET-PARAMS, GET-PARAMS, RECOGNIZE n-best-list-length Optional SET-PARAMS, GET-PARAMS, RECOGNIZE, GET-RESULT no-input-timeout MANDATORY SET-PARAMS, GET-PARAMS, RECOGNIZE
自信しきい値MANDATORY SET - PARAMS、オプションのnベストリストの長さを認識し、GET-PARAMSを、スピード-VS-精度オプションSET-PARAMSを認識し、GET-PARAMSを、GET-結果を感度レベルのオプションSET-PARAMSを認識SET- PARAMS、認識し-PARAMSをGET、無入力タイムアウトMANDATORY SET - PARAMS GET結果、認識し-PARAMSをGETしません
recognition-timeout MANDATORY SET-PARAMS, GET-PARAMS, RECOGNIZE waveform-url MANDATORY RECOGNITION-COMPLETE completion-cause MANDATORY DEFINE-GRAMMAR, RECOGNIZE, RECOGNITON-COMPLETE recognizer-context-block Optional SET-PARAMS, GET-PARAMS recognizer-start-timers MANDATORY RECOGNIZE vendor-specific MANDATORY SET-PARAMS, GET-PARAMS speech-complete-timeout MANDATORY SET-PARAMS, GET-PARAMS RECOGNIZE speech-incomplete-timeout MANDATORY SET-PARAMS, GET-PARAMS RECOGNIZE dtmf-interdigit-timeout MANDATORY SET-PARAMS, GET-PARAMS RECOGNIZE dtmf-term-timeout MANDATORY SET-PARAMS, GET-PARAMS RECOGNIZE dtmf-term-char MANDATORY SET-PARAMS, GET-PARAMS RECOGNIZE fetch-timeout MANDATORY SET-PARAMS, GET-PARAMS RECOGNIZE, DEFINE-GRAMMAR failed-uri MANDATORY DEFINE-GRAMMAR response, RECOGNITION-COMPLETE failed-uri-cause MANDATORY DEFINE-GRAMMAR response, RECOGNITION-COMPLETE save-waveform MANDATORY SET-PARAMS, GET-PARAMS, RECOGNIZE new-audio-channel MANDATORY RECOGNIZE speech-language MANDATORY SET-PARAMS, GET-PARAMS, RECOGNIZE, DEFINE-GRAMMAR
認識タイムアウトMANDATORY SET - PARAMS、GET-PARAMS RECOGNIZE、波形URL MANDATORY認識COMPLETE完了原因MANDATORY DEFINE文法、RECOGNITON-COMPLETEを認識し、認識コンテキスト・ブロックオプションSET-PARAMS、GET-PARAMS認識装置、[スタート] GET-PARAMSを音声完全タイムアウトMANDATORY SET - PARAMS、ベンダー固有のMANDATORY SET-PARAMSを認識し、GET-PARAMSは音声不完全タイムアウトMANDATORY SET - PARAMSを認識し、GET-PARAMSがDTMF-桁間タイムアウトMANDATORY SET-を認識MANDATORYタイマーPARAMS、GET-PARAMSがDTMF項タイムアウトMANDATORY SET-PARAMS、GET-PARAMSが認識DTMF項-チャーMANDATORY SET-PARAMS、GET-PARAMSは、フェッチタイムアウトMANDATORY SET-PARAMS、GET-PARAMSが認識認識DEFINE文法を認識URI-失敗MANDATORY DEFINE-文法を応答、認識COMPLETE失敗-uriの原因、応答MANDATORY-文法DEFINE認識COMPLETEセーブ・波形MANDATORY SET - PARAMS、GET-PARAMSを、MANDATORY新しいオーディオチャンネルMANDATORY RECOGNIZE音声言語を認識SET-PARAMS、 GET-PARAMS、認識しDEFINE - GRAMMAR
When a recognition resource recognizes or matches a spoken phrase with some portion of the grammar, it associates a confidence level with that conclusion. The confidence-threshold parameter tells the recognizer resource what confidence level should be considered a successful match. This is an integer from 0-100 indicating the recognizer's confidence in the recognition. If the recognizer determines that its confidence in all its recognition results is less than the confidence threshold, then it MUST return no-match as the recognition result. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. The default value for this field is platform specific.
認識リソースは文法の一部で話さフレーズを認識するか、一致した場合、その結論と信頼性のレベルを関連付けます。信頼-thresholdパラメータは、信頼レベルが成功した一致と見なされるべきものを、認識資源を伝えます。これは、認識における認識器の信頼を示す0〜100の整数です。認識装置は、そのすべての認識結果での信頼が信頼閾値未満であると判断した場合、それは認識結果として何のマッチを返してはなりません。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。このフィールドのデフォルト値は、プラットフォーム固有です。
confidence-threshold = "Confidence-Threshold" ":" 1*DIGIT CRLF
自信しきい値= "自信-しきい値" "：" 1 * DIGIT CRLF
To filter out background noise and not mistake it for speech, the recognizer may support a variable level of sound sensitivity. The sensitivity-level parameter allows the client to set this value on the recognizer. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. A higher value for this field means higher sensitivity. The default value for this field is platform specific.
バックグラウンドノイズをフィルタリングし、スピーチのためにそれを間違えないように、認識は、音声感度の可変レベルをサポートすることができます。感度レベルのパラメータは、クライアントが、認識にこの値を設定することができます。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。このフィールドの値が高いほど、より高い感度を意味します。このフィールドのデフォルト値は、プラットフォーム固有です。
sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF
感度レベル=「感度レベル」「：」1 * DIGIT CRLF
Depending on the implementation and capability of the recognizer resource, it may be tunable towards Performance or Accuracy. Higher accuracy may mean more processing and higher CPU utilization, meaning less calls per media server and vice versa. This parameter on the resource can be tuned by the speed-vs-accuracy header. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. A higher value for this field means higher speed. The default value for this field is platform specific.
認識器リソースの実装と能力に応じて、パフォーマンスや精度に向けて調整可能することができます。高い精度は、メディアサーバーおよびその逆あたり以下のコールを意味し、より多くの処理と高いCPU使用率を意味するかもしれません。リソース上のこのパラメータは、速度対精度ヘッダことによって調整することができます。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。このフィールドの値が大きいほど、より高速を意味します。このフィールドのデフォルト値は、プラットフォーム固有です。
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 1*DIGIT CRLF
スピード-VS-精度= "スピード対精度" "：" 1 * DIGIT CRLF
When the recognizer matches an incoming stream with the grammar, it may come up with more than one alternative match because of confidence levels in certain words or conversation paths. If this header field is not specified, by default, the recognition resource will only return the best match above the confidence threshold. The client, by setting this parameter, could ask the recognition resource to send it more than 1 alternative. All alternatives must still be above the confidence-threshold. A value greater than one does not guarantee that the recognizer will send the requested number of alternatives. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. The minimum value for this field is 1. The default value for this field is 1.
認識文法の着信ストリームと一致した場合、それがために特定の単語や会話の経路における信頼レベルの複数の代替的な一致を思い付くことができます。このヘッダフィールドが指定されていない場合、デフォルトでは、認識リソースは信頼閾値以上のベストマッチを返します。クライアントは、このパラメータを設定することで、それを超える1つの選択肢を送信するために認識リソースを求めることができます。すべての代替案は、まだ自信しきい値を超えていなければなりません。 1より大きい値は、認識が代替案の要求された数を送信することを保証するものではありません。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。このフィールドのデフォルト値は1です。1.このフィールドの最小値です。
n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF
nベストリスト長= "N-ベスト・リスト長" "：" 1 * DIGIT CRLF
When recognition is started and there is no speech detected for a certain period of time, the recognizer can send a RECOGNITION-COMPLETE event to the client and terminate the recognition operation. The no-input-timeout header field can set this timeout value. The value is in milliseconds. This header field MAY occur in RECOGNIZE,
認識が開始され、一定時間検出全く音声が存在しない場合には、認識装置は、クライアントに認識COMPLETEイベントを送信して認識動作を終了することができます。無入力タイムアウトヘッダフィールドは、このタイムアウト値を設定することができます。値はミリ秒単位です。このヘッダーフィールドは、RECOGNIZEで起こり得ます
SET-PARAMS, or GET-PARAMS. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific.
SET-PARAMS、またはGET - PARAMS。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。このフィールドのデフォルト値は、プラットフォーム固有です。
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
無入力タイムアウト=「無入力タイムアウト」「：」1 * DIGIT CRLF
When recognition is started and there is no match for a certain period of time, the recognizer can send a RECOGNITION-COMPLETE event to the client and terminate the recognition operation. The recognition-timeout parameter field sets this timeout value. The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value is 10 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS or GET-PARAMS.
認識が開始され、一定の期間のための一致がない場合には、認識装置は、クライアントに認識COMPLETEイベントを送信して認識動作を終了することができます。認識-timeoutパラメータフィールドは、このタイムアウト値を設定します。値はミリ秒単位です。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。デフォルト値は10秒です。このヘッダーフィールドは、SET-PARAMSかGET-PARAMS、中に発生し認識することができます。
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
認識タイムアウト=「認識タイムアウト」「：」1 * DIGIT CRLF
If the save-waveform header field is set to true, the recognizer MUST record the incoming audio stream of the recognition into a file and provide a URI for the client to access it. This header MUST be present in the RECOGNITION-COMPLETE event if the save-waveform header field was set to true. The URL value of the header MUST be NULL if there was some error condition preventing the server from recording. Otherwise, the URL generated by the server SHOULD be globally unique across the server and all its recognition sessions. The URL SHOULD BE available until the session is torn down.
保存波形ヘッダフィールドをtrueに設定すると、認識装置は、ファイルへの認識の着信オーディオストリームを記録し、それをアクセスするためのクライアントのためのURIを提供しなければなりません。保存波形のヘッダフィールドがtrueに設定された場合、このヘッダが認識COMPLETEイベント中に存在しなければなりません。記録からサーバーを防止するいくつかのエラー状態が発生した場合、ヘッダのURL値はNULLでなければなりません。そうでない場合は、サーバーによって生成されたURLには、サーバーとそのすべての認識セッション間でグローバルに一意であるべきです。セッションが切断されるまでのURLは利用可能であるべきです。
waveform-url = "Waveform-URL" ":" Url CRLF
波形のurl = "波形-URL" "：" URL CRLF
This header field MUST be part of a RECOGNITION-COMPLETE event coming from the recognizer resource to the client. This indicates the reason behind the RECOGNIZE method completion. This header field MUST BE sent in the DEFINE-GRAMMAR and RECOGNIZE responses, if they return with a failure status and a COMPLETE state.
このヘッダーフィールドは、クライアントに認識リソースから来る認識COMPLETEイベントの一部でなければなりません。これは、メソッドを認識完了の背後にある理由を示します。このヘッダーフィールドは、DEFINE-文法で送信され、彼らは失敗のステータスとCOMPLETE状態に戻る場合は、応答を認識しなければなりません。
Cause-Code Cause-Name Description
原因 - 名説明 - コードの原因
000 success RECOGNIZE completed with a match or DEFINE-GRAMMAR succeeded in downloading and compiling the grammar
000成功は試合で完了またはDEFINE-文法が認識文法をダウンロードしてコンパイルすることに成功しました
001 no-match RECOGNIZE completed, but no match was found 002 no-input-timeout RECOGNIZE completed without a match due to a no-input-timeout 003 recognition-timeout RECOGNIZE completed without a match due to a recognition-timeout 004 gram-load-failure RECOGNIZE failed due grammar load failure. 005 gram-comp-failure RECOGNIZE failed due to grammar compilation failure. 006 error RECOGNIZE request terminated prematurely due to a recognizer error. 007 speech-too-early RECOGNIZE request terminated because speech was too early. 008 too-much-speech-timeout RECOGNIZE request terminated because speech was too long. 009 uri-failure Failure accessing a URI. 010 language-unsupported Language not supported.
001無マッチが完了しない認識が、一致が002無入力タイムアウトによる無入力タイムアウト003認識タイムアウトに一致せずに完了認識見出されなかった原因認識タイムアウト004グラム負荷に一致せずに完了認識失敗した原因文法ロード障害を認識-failure。 005グラム-COMP-失敗は文法のコンパイルの失敗に失敗を認識します。 006エラーは、認識エラーのために途中で終了要求を認識しています。スピーチが早すぎたので、007のスピーチは、あまりにも早期に終了要求を認識しています。スピーチが長すぎたので、008あまりにも多くの音声・タイムアウトが終了し、要求を認識しています。 URIにアクセスする009 URI-失敗失敗。 010言語のサポートされていない言語がサポートされていません。
This parameter MAY BE sent as part of the SET-PARAMS or GET-PARAMS request. If the GET-PARAMS method contains this header field with no value, then it is a request to the recognizer to return the recognizer context block. The response to such a message MAY contain a recognizer context block as a message entity. If the server returns a recognizer context block, the response MUST contain this header field and its value MUST match the content-id of that entity.
このパラメータは、SET-PARAMSかGET - PARAMS要求の一部として送信することができます。 GET-PARAMS法はない値でこのヘッダーフィールドが含まれている場合、認識コンテキスト・ブロックを返す認識するための要求です。このようなメッセージに対する応答メッセージエンティティとして認識コンテキスト・ブロックを含むかもしれません。サーバが認識コンテキスト・ブロックを返した場合、応答は、このヘッダーフィールドを含まなければなりません、その値は、そのエンティティのコンテンツIDと一致しなければなりません。
If the SET-PARAMS method contains this header field, it MUST contain a message entity containing the recognizer context data, and a content-id matching this header field.
SET-PARAMS法は、このヘッダーフィールドが含まれている場合、それは認識コンテキストデータを含むメッセージ・エンティティ、及びコンテンツIDに一致するこのヘッダーフィールドを含まなければなりません。
This content-id should match the content-id that came with the context data during the GET-PARAMS operation.
このコンテンツIDはGET-PARAMS操作中にコンテキストデータに付属しているコンテンツIDと一致する必要があります。
recognizer-context-block = "Recognizer-Context-Block" ":" 1*ALPHA CRLF
認識エンジンコンテキスト・ブロック= "認識装置-コンテキストブロック" "：" 1 * ALPHA CRLF
This parameter MAY BE sent as part of the RECOGNIZE request. A value of false tells the recognizer to start recognition, but not to start the no-input timer yet. The recognizer should not start the timers until the client sends a RECOGNITION-START-TIMERS request to the recognizer. This is useful in the scenario when the recognizer and synthesizer engines are not part of the same session. Here, when a kill-on-barge-in prompt is being played, you want the RECOGNIZE request to be simultaneously active so that it can detect and implement kill-on-barge-in. But at the same time, you don't want the recognizer to start the no-input timers until the prompt is finished. The default value is "true".
このパラメータを認識要求の一部として送信されてもよいです。偽の値は、認識を開始するには、まだ無入力のタイマーを起動していない、認識を伝えます。クライアントが認識装置に認識-START-TIMERS要求を送信するまで認識器はタイマを起動してはいけません。認識装置とシンセサイザーエンジンは同じセッションの一部でない場合は、このシナリオで有用です。ここでは、キル・オン・バージ・インプロンプトが再生されているとき、あなたはそれがキル・オン・はしけインを検出し、実装することができるように同時にアクティブにすることを認識リクエストをしたいです。しかし同時に、プロンプトが終了するまで、認識が無入力のタイマーを起動する必要はありません。デフォルト値は「true」です。
recognizer-start-timers = "Recognizer-Start-Timers" ":" boolean-value CRLF
認識エンジン・スタート・タイマー=「認識器スタート・タイマー」「：」ブール値CRLF
This set of headers allows the client to set Vendor Specific parameters.
ヘッダのこのセットは、クライアントがベンダー固有のパラメータを設定することができます。
This header can be sent in the SET-PARAMS method and is used to set vendor-specific parameters on the server. The vendor-av-pair-name can be any vendor-specific field name and conforms to the XML vendor-specific attribute naming convention. The vendor-av-pair-value is the value to set the attribute to, and needs to be quoted.
このヘッダは、SET-PARAMS方法で送信することができ、サーバ上のベンダー固有のパラメータを設定するために使用されています。ベンダーのAVペア名は、任意のベンダー固有のフィールド名であるとXMLベンダー固有の属性の命名規則に準拠することができます。ベンダーのAVペア値はに属性を設定する値であり、引用符で囲む必要があります。
When asking the server to get the current value of these parameters, this header can be sent in the GET-PARAMS method with the list of vendor-specific attribute names to get separated by a semicolon. This header field MAY occur in SET-PARAMS or GET-PARAMS.
これらのパラメータの現在の値を取得するには、サーバーを尋ねるときは、このヘッダは、セミコロンで区切って取得するために、ベンダー固有の属性名のリストとGET-PARAMSメソッドで送信することができます。このヘッダーフィールドは、SET-PARAMSに起こるか-PARAMSを得ることができます。
This header field specifies the length of silence required following user speech before the speech recognizer finalizes a result (either accepting it or throwing a nomatch event). The speech-complete-timeout value is used when the recognizer currently has a complete match of an active grammar, and specifies how long it should wait for more input before declaring a match. By contrast, the incomplete timeout is used when the speech is an incomplete match to an active grammar. The value is in milliseconds.
音声認識は、（それを受け入れるか、NOMATCHイベントを投げるのいずれか）の結果を確定する前に、このヘッダーフィールドは、無音必要な次のユーザ音声の長さを指定します。認識装置は、現在アクティブな文法の完全な一致を持っており、それが試合を宣言する前に、複数の入力を待機する時間を指定したときに音声の完全なタイムアウト値が使用されます。音声がアクティブな文法に不完全一致である場合に対照的に、不完全タイムアウトが使用されています。値はミリ秒単位です。
speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*DIGIT CRLF
音声の完全タイムアウト=「スピーチコンプリート・タイムアウト」「：」1 * DIGIT CRLF
A long speech-complete-timeout value delays the result completion and, therefore, makes the computer's response slow. A short speech-complete-timeout may lead to an utterance being broken up inappropriately. Reasonable complete timeout values are typically in the range of 0.3 seconds to 1.0 seconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
長いスピーチ - 完全 - タイムアウト値は、結果の完了を遅延させ、そのため、コンピュータの応答が遅くなります。短いスピーチ - 完全 - タイムアウトが不適切に分割された発声につながる可能性があります。合理的な完全なタイムアウト値は、1.0秒、0.3秒の範囲で、一般的です。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。このフィールドのデフォルト値は、プラットフォーム固有です。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。
This header field specifies the required length of silence following user speech, after which a recognizer finalizes a result. The incomplete timeout applies when the speech prior to the silence is an incomplete match of all active grammars. In this case, once the timeout is triggered, the partial result is rejected (with a nomatch event). The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific.
このヘッダーフィールドは、認識結果を確定その後ユーザ音声、以下沈黙の必要な長さを指定します。前沈黙の音声がすべてのアクティブな文法の不完全な一致である場合、不完全なタイムアウトが適用されます。タイムアウトがトリガーされると、この場合には、部分的な結果は、（NOMATCHイベントに）拒否されます。値はミリ秒単位です。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。このフィールドのデフォルト値は、プラットフォーム固有です。
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*DIGIT CRLF
音声不完全タイムアウト= "スピーチ-不完全タイムアウト" "：" 1 * DIGIT CRLF
The speech-incomplete-timeout also applies when the speech prior to the silence is a complete match of an active grammar, but where it is possible to speak further and still match the grammar. By contrast, the complete timeout is used when the speech is a complete match to an active grammar and no further words can be spoken.
前沈黙のスピーチがアクティブな文法の完全一致であるとき、音声不完全タイムアウトも適用されますが、さらに話すと、まだ文法を一致させることも可能です。対照的に、完全なタイムアウトは音声がアクティブな文法に完全一致である場合に使用され、それ以上の言葉が話さないことができます。
A long speech-incomplete-timeout value delays the result completion and, therefore, makes the computer's response slow. A short speech-incomplete-timeout may lead to an utterance being broken up inappropriately.
長いスピーチ - 不完全なタイムアウト値は、結果の完了を遅延させ、そのため、コンピュータの応答が遅くなります。短い音声不完全タイムアウトが不適切に分割された発話につながる可能性があります。
The speech-incomplete-timeout is usually longer than the speech-complete-timeout to allow users to pause mid-utterance (for example, to breathe). This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
音声不完全タイムアウトは、ユーザーが（例えば、呼吸する）ミッド発話を一時停止できるようにするために長いスピーチ - 完全 - タイムアウトより通常です。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。
This header field specifies the inter-digit timeout value to use when recognizing DTMF input. The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value is 5 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドは、DTMF入力を認識するときに使用するインターディジットタイムアウト値を指定します。値はミリ秒単位です。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。デフォルト値は5秒です。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*DIGIT CRLF
DTMF-桁間タイムアウト= "DTMF-ディジット間のタイムアウト" "：" 1 * DIGIT CRLF
This header field specifies the terminating timeout to use when recognizing DTMF input. The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value is 10 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドは、DTMF入力を認識するときに使用する終端タイムアウトを指定します。値はミリ秒単位です。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。デフォルト値は10秒です。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
DTMF-用語タイムアウト= "DTMF-ターム・タイムアウト" "：" 1 * DIGIT CRLF
This header field specifies the terminating DTMF character for DTMF input recognition. The default value is NULL which is specified as an empty header field. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドは、DTMF入力認識のための終端DTMF文字を指定します。デフォルト値は、空のヘッダフィールドとして指定されたNULLです。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。
dtmf-term-char = "DTMF-Term-Char" ":" CHAR CRLF
DTMF-用語-CHAR = "DTMF-ターム・シャア" "：" CHAR CRLF
When the recognizer needs to fetch grammar documents, this header field controls URI access properties. This defines the recognizer timeout for completing the fetch of the resources the media server needs from the network. The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
認識装置は、文法書を取得する必要がある場合、このヘッダーフィールドはURIアクセスの特性を制御します。これは、メディアサーバがネットワークから必要なリソースのフェッチを完了するため、認識のタイムアウトを定義します。値はミリ秒単位です。 MAXTIMEOUTはプラットフォーム固有である場合、このフィールドの値は、0からMAXTIMEOUTの範囲です。このフィールドのデフォルト値は、プラットフォーム固有です。このヘッダーフィールドは、RECOGNIZE SET-PARAMS、または-PARAMSをGETで発生することがあります。
When a recognizer method needs a recognizer to fetch or access a URI, and the access fails, the media server SHOULD provide the failed URI in this header field in the method response.
認識方法は、URIを取得又はアクセスするための認識を必要とし、アクセスが失敗した場合、メディアサーバは、メソッド応答してこのヘッダフィールドに失敗したURIを提供すべきです。
When a recognizer method needs a recognizer to fetch or access a URI, and the access fails, the media server SHOULD provide the URI-specific or protocol-specific response code through this header field in the method response. This field has been defined as alphanumeric to accommodate all protocols, some of which might have a response string instead of a numeric response code.
認識方法はフェッチまたはURIにアクセスするための認識を必要とし、アクセスが失敗した場合、メディアサーバは、メソッド応答におけるこのヘッダフィールドを介してURI固有またはプロトコル特有の応答コードを提供しなければなりません。このフィールドではなく、数値応答コードの応答文字列を持っているかもしれないいくつかのそれらのすべてのプロトコルを、対応するために、英数字として定義されています。
This header field allows the client to indicate to the recognizer that it MUST save the audio stream that was recognized. The recognizer MUST then record the recognized audio and make it available to the client in the form of a URI returned in the waveform-uri header field in the RECOGNITION-COMPLETE event. If there was an error in recording the stream or the audio clip is otherwise not available, the recognizer MUST return an empty waveform-uri header field. The default value for this fields is "false".
このヘッダーフィールドは、クライアントが、それが認識されたオーディオストリームを保存する必要があり、認識に示すことができます。認識装置は、認識された音声を録音し、URIの形式でクライアントが使用できるようにしなければならRECOGNITION-COMPLETEイベントで波形-URIヘッダフィールドに戻りました。ストリームまたはオーディオクリップを録音中にエラーがそうでなければ利用できないがあった場合、認識は空波形-URIヘッダフィールドを返さなければなりません。このフィールドのデフォルト値は「false」です。
save-waveform = "Save-Waveform" ":" boolean-value CRLF
保存波形=「「波形を保存」：」ブール値CRLF
This header field MAY BE specified in a RECOGNIZE message and allows the client to tell the media server that, from that point on, it will be sending audio data from a new audio source, channel, or speaker. If the recognition resource had collected any line statistics or information, it MUST discard it and start fresh for this RECOGNIZE. This helps in the case where the client MAY want to reuse an open recognition session with the media server for multiple telephone calls.
このヘッダーフィールドを認識メッセージで指定され、クライアントがその時点から、それは新しいオーディオソース、チャネル、またはスピーカーからの音声データを送信される、メディアサーバに伝えることができますされる可能性あり。認識リソースがどの回線の統計や情報を収集していた場合、それを捨てなければなりませんし、これが認識のために、新鮮なスタート。これは、クライアントが複数の電話コールのメディアサーバとオープン認識セッションを再利用することができます場合に役立ちます。
new-audio-channel = "New-Audio-Channel" ":" boolean-value CRLF
新しいオーディオ・チャンネル=「新しいオーディオチャンネル」「：」ブール値CRLF
This header field specifies the language of recognition grammar data within a session or request, if it is not specified within the data. The value of this header field should follow RFC 3066 [16] for its values. This MAY occur in DEFINE-GRAMMAR, RECOGNIZE, SET-PARAMS, or GET-PARAMS request.
それはデータの中に指定されていない場合は、このヘッダフィールドは、セッションまたはリクエスト内の認識文法データの言語を指定します。このヘッダーフィールドの値は、その値の[16] RFC 3066に従うべきです。これは、文法定義、SET-PARAMSを認識し、またはGET - PARAMS要求をに発生することがあります。
A recognizer message may carry additional data associated with the method, response, or event. The client may send the grammar to be recognized in DEFINE-GRAMMAR or RECOGNIZE requests. When the grammar is sent in the DEFINE-GRAMMAR method, the server should be able to download compile and optimize the grammar. The RECOGNIZE request MUST contain a list of grammars that need to be active during the recognition. The server resource may send the recognition results in the RECOGNITION-COMPLETE event or the GET-RESULT response. This data will be carried in the message body of the corresponding MRCP message.
認識メッセージは、メソッド、応答、またはイベントに関連する追加データを搬送することができます。クライアントは、イン文法を定義したり、要求を認識認識される文法を送ることができます。文法はDEFINE - GRAMMAR方式で送信されると、サーバーは、コンパイルをダウンロードして、文法を最適化することができるはずです。要求が認識時にアクティブにする必要がある文法のリストを指定する必要があります認識しています。サーバリソースは認識COMPLETEイベントまたはGET-結果応答で認識結果を送信することができます。このデータは、対応するMRCPメッセージのメッセージ本体で搬送されます。
Recognizer grammar data from the client to the server can be provided inline or by reference. Either way, they are carried as MIME entities in the message body of the MRCP request message. The grammar specified inline or by reference specifies the grammar used to match in the recognition process and this data is specified in one of the standard grammar specification formats like W3C's XML or ABNF or Sun's Java Speech Grammar Format, etc. All media servers MUST support W3C's XML based grammar markup format [11] (MIME-type application/grammar+xml) and SHOULD support the ABNF form (MIME-type application/grammar).
クライアントからサーバへの認識文法データは、インラインまたは参照することによって提供することができます。いずれにせよ、彼らはMRCP要求メッセージのメッセージ本文のMIMEエンティティとして実施されています。文法は、インラインを指定したり、参照することによって文法が認識プロセスに一致させるために使用され、このデータはすべてのメディアサーバーは、W3CのをサポートしなければならないW3CのXMLまたはABNFまたはSunのJavaスピーチ文法フォーマットのような標準的な文法仕様の形式のいずれか、などに指定されている指定XMLベースの文法マークアップ形式[11]（MIMEタイプアプリケーション/文法+ XML）とABNFフォームをサポートするべきである（MIMEタイプアプリケーション/文法）。
When a grammar is specified in-line in the message, the client MUST provide a content-id for that grammar as part of the content headers. The server MUST store the grammar associated with that content-id for the duration of the session. A stored grammar can be overwritten by defining a new grammar with the same content-id. Grammars that have been associated with a content-id can be referenced through a special "session:" URI scheme.
文法がメッセージにインラインで指定された場合、クライアントはコンテンツヘッダーの一部として、その文法のためのコンテンツIDを提供しなければなりません。サーバは、セッションの間、そのコンテンツIDに関連付けられた文法を記憶しなければなりません。格納された文法は同じコンテンツIDと新しい文法を定義することによって上書きすることができます。 URIスキーム：コンテンツIDに関連付けられている文法は、特別な「セッション」を介して参照することができます。
Example: session:help@root-level.store
例：セッション：help@root-level.store
If grammar data needs to be specified by external URI reference, the MIME-type text/uri-list is used to list the one or more URI that will specify the grammar data. All media servers MUST support the HTTP URI access mechanism.
文法データが外部URI参照で指定する必要がある場合は、MIMEタイプtext / URIリストは、文法データを指定します一つ以上のURIを一覧表示するために使用されます。すべてのメディアサーバーは、HTTP URIのアクセスメカニズムをサポートしなければなりません。
If the data to be defined consists of a mix of URI and inline grammar data, the multipart/mixed MIME-type is used and embedded with the MIME-blocks for text/uri-list, application/grammar or application/grammar+xml. The character set and encoding used in the grammar data may be specified according to standard MIME-type definitions.
定義すべきデータがURIとインライン文法データの混在で構成されている場合、混合/マルチパートMIMEタイプを使用し、テキスト/ URIリスト、アプリケーション/文法またはアプリケーション/文法+ XMLのMIMEブロックが埋め込まれています。文法データに使用される文字セットと符号化は、標準的なMIMEタイプの定義に従って指定することができます。
When more than one grammar URI or inline grammar block is specified in a message body of the RECOGNIZE request, it is an active list of grammar alternatives to listen. The ordering of the list implies the precedence of the grammars, with the first grammar in the list having the highest precedence.
複数の文法URIまたはインライン文法ブロックはRECOGNIZE要求のメッセージボディに指定されている場合、それは聞くために文法選択肢のアクティブリストです。リストの順序は、最も高い優先度を持つリストの最初の文法で、文法の優先順位を意味します。
Example 1: Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104
実施例1：コンテンツタイプ：アプリケーション/文法+ XMLコンテンツID：request1@form-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
<！ - トークンに単一の言語の添付ファイル - > <ルールID = "はい"> <1-の> <項目のXML：LANG = "FR-CA"> OUI </ item>の<アイテムのXML：LANG = "EN -US ">はい</ item>の</> </ルール1-の>
<!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私はに話すことがあり、<1-のXML：LANG = "FR-CA"> <項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
<!-- multiple language attachment to a token --> <rule id="people1"> <token lexicon="en-US,fr-CA"> Robert </token> </rule>
<！ - トークンに複数の言語アタッチメント - > <ルールID = "人1"> <トークン辞書= "EN-US、FR-CA">ロバート</トークン> </ルール>
<!-- the equivalent single-language attachment expansion --> <rule id="people2"> <one-of> <item xml:lang="en-US">Robert</item> <item xml:lang="fr-CA">Robert</item> </one-of> </rule>
<ルールID = "people2の"> <1-の> < - - 同等の単一言語アタッチメント展開！> <商品のxml：langは= "EN-US">ロバート</ item>の<アイテムのXML：LANG = "FR-CA">ロバート</ item>の</ワンの> </ルール>
</grammar>
</文法>
Example 2: Content-Type:text/uri-list Content-Length:176
例2：コンテンツタイプ：テキスト/ URIリストのContent-Length：176
session:help@root-level.store http://www.cisco.com/Directory-Name-List.grxml http://www.cisco.com/Department-List.grxml http://www.cisco.com/TAC-Contact-List.grxml session:menu1@menu-level.store
セッション：help@root-level.store http://www.cisco.com/Directory-Name-List.grxml http://www.cisco.com/Department-List.grxml http://www.cisco.com /TAC-Contact-List.grxmlセッション：menu1@menu-level.store
Example 3: Content-Type:multipart/mixed; boundary="--break"
例3：コンテンツタイプ：混合/マルチパート。境界=「 - ブレイク」
--break Content-Type:text/uri-list Content-Length:176 http://www.cisco.com/Directory-Name-List.grxml http://www.cisco.com/Department-List.grxml http://www.cisco.com/TAC-Contact-List.grxml
--breakのContent-Type：uriテキスト/リストのContent-Length：176 http://www.cisco.com/Directory-Name-List.grxml http://www.cisco.com/Department-List.grxml HTTP ：//www.cisco.com/TAC-Contact-List.grxml
--break Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104
--breakコンテンツタイプ：アプリケーション/文法+ XMLコンテンツID：request1@form-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
<！ - トークンに単一の言語の添付ファイル - > <ルールID = "はい"> <1-の> <項目のXML：LANG = "FR-CA"> OUI </ item>の<アイテムのXML：LANG = "EN -US ">はい</ item>の</> </ルール1-の>
<!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私はに話すことがあり、<1-のXML：LANG = "FR-CA"> <項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
<!-- multiple language attachment to a token --> <rule id="people1"> <token lexicon="en-US,fr-CA"> Robert </token> </rule>
<！ - トークンに複数の言語アタッチメント - > <ルールID = "人1"> <トークン辞書= "EN-US、FR-CA">ロバート</トークン> </ルール>
<!-- the equivalent single-language attachment expansion -->
<！ - 同等の単一言語の添付ファイルの拡張 - >
<rule id="people2"> <one-of> <item xml:lang="en-US">Robert</item> <item xml:lang="fr-CA">Robert</item> </one-of> </rule>
<ルールID = "people2の"> <1-の> <項目のXML：LANG = "EN-US">ロバート</ item>の<アイテムのXML：LANG = "FR-CA">ロバート</ item>の</ 1 -of> </ルール>
</grammar> --break
</文法> --break
Recognition result data from the server is carried in the MRCP message body of the RECOGNITION-COMPLETE event or the GET-RESULT response message as MIME entities. All media servers MUST support W3C's Natural Language Semantics Markup Language (NLSML) [10] as the default standard for returning recognition results back to the client, and hence MUST support the MIME-type application/x-nlsml.
サーバから認識結果データは、MIMEエンティティとして認識COMPLETEイベントまたはGET-結果応答メッセージのMRCPのメッセージ本体で運ばれます。すべてのメディアサーバーは、クライアントに認識結果を返すためのデフォルトの標準として[10] W3Cの自然言語の意味論マークアップ言語（NLSML）をサポートする必要があり、それゆえMIMEタイプのアプリケーション/ X-nlsmlをサポートしなければなりません。
Example 1: Content-Type:application/x-nlsml Content-Length:104
実施例1：コンテンツタイプ：アプリケーション/ X-nlsmlのContent-Length：104
<?xml version="1.0"?> <result grammar="http://theYesNoGrammar"> <interpretation> <instance> <myApp:yes_no> <response>yes</response> </myApp:yes_no> </instance> <input>ok</input> </interpretation> </result>
<？xmlのバージョン= "1.0"> <結果文法= "のhttp：// theYesNoGrammar"> <解釈> <インスタンス> <て、myApp：yes_no> <応答>はい</レスポンス> </て、myApp：yes_no> </インスタンス> <入力> OK </入力> </通訳> </結果>
When the client has to change recognition servers within a call, this is a block of data that the client MAY collect from the first media server and provide to the second media server. This may be because the client needs different language support or because the media server issued an RTSP RE-DIRECT. Here, the first recognizer may have collected acoustic and other data during its recognition. When we switch recognition servers, communicating this data may allow the second recognition server to provide better recognition based on the acoustic data collected by the previous recognizer. This block of data is vendor-specific and MUST be carried as MIME-type application/octets in the body of the message.
クライアントがコール内で認識サーバを変更する必要がある場合、これは、クライアントが最初のメディアサーバーから収集し、第2のメディアサーバーに提供できることデータのブロックです。クライアントは、異なる言語のサポートを必要とするため、またはメディアサーバーがRTSP RE-DIRECTを発行したためと考えられます。ここでは、最初の認識装置は、その認識の間に音響やその他のデータを収集している可能性があります。我々は認識サーバを切り替えると、このデータを通信する第2の認識サーバは、以前の認識器によって収集された音響データに基づいて、より良い認識を提供することを可能にします。このデータのブロックは、ベンダー固有のものであり、メッセージの本文に、MIMEタイプapplication /オクテットとして実行されなければなりません。
This block of data is communicated in the SET-PARAMS and GET-PARAMS method/response messages. In the GET-PARAMS method, if an empty recognizer-context-block header field is present, then the recognizer should return its vendor-specific context block in the message body as a MIME-entity with a specific content-id. The content-id value should also be specified in the recognizer-context-block header field in the GET-PARAMS response. The SET-PARAMS request wishing to provide this vendor-specific data should send it in the message body as a MIME-entity with the same content-id that it received from the GET-PARAMS. The content-id should also be sent in the recognizer-context-block header field of the SET-PARAMS message.
このデータのブロックは、SET-PARAMSで通信し、GET-PARAMSメソッド/応答メッセージれます。空認識コンテキストブロックヘッダフィールドが存在する場合、GET-PARAMS方法では、その後、認識装置は、特定のコンテンツIDとMIMEエンティティとしてメッセージ本文に、そのベンダー固有のコンテキスト・ブロックを返すべきです。コンテンツIDの値は、GET-PARAMS応答の認識コンテキストブロックヘッダフィールドで指定されるべきです。このベンダー固有のデータを提供することを望むSET-PARAMS要求は、GET-PARAMSから受信した同一のコンテンツIDとMIMEエンティティとしてメッセージ本文にそれを送るべきです。コンテンツIDはまた、SET-PARAMSメッセージの認識コンテキストブロックヘッダ・フィールドで送られるべきです。
Each automatic speech recognition (ASR) vendor choosing to use this mechanism to handoff recognizer context data among its servers should distinguish its vendor-specific block of data from other vendors by choosing a unique content-id that they should recognize.
各自動音声認識（ASR）のサーバ間でのハンドオフ認識器コンテキストデータにこのメカニズムを使用することを選択するベンダーは、彼らが認識しなければならないユニークなコンテンツIDを選択することで、他のベンダーからのデータのそのベンダー固有のブロックを区別する必要があります。
The SET-PARAMS method, from the client to the server, tells the recognizer resource to set and modify recognizer context parameters like recognizer characteristics, result detail level, etc. In the following sections some standard parameters are discussed. If the server resource does not recognize an OPTIONAL parameter, it MUST ignore that field. Many of the parameters in the SET-PARAMS method can also be used in another method like the RECOGNIZE method. But the difference is that when you set something like the sensitivity-level using the SET-PARAMS, it applies for all future requests, whenever applicable. On the other hand, when you pass sensitivity-level in a RECOGNIZE request, it applies only to that request.
SET-PARAMS方法、クライアントからサーバには、いくつかの標準的なパラメータが議論されている次のセクションでなど、設定および変更認識特性のようなレコグナイザコンテキストパラメータを、詳細レベルをもたらすために認識リソースを伝えます。サーバリソースはオプションのパラメータを認識しない場合は、そのフィールドを無視しなければなりません。 SET-PARAMSメソッドのパラメータの多くは、RECOGNIZE方法など他の方法で使用することができます。しかし、違いは、SET-PARAMSを使用して感度レベルのようなものを設定したときにいつでも適用可能な、それは、将来のすべての要求に適用されるということです。あなたが認識し、要求に感度レベルを渡すとき、一方、それだけでその要求に適用されます。
Example: C->S:SET-PARAMS 543256 MRCP/1.0 Sensitivity-Level:20 Recognition-Timeout:30 Confidence-Threshold:85
例：C-> S：SET-PARAMS 543256 MRCP / 1.0感度レベル：20認識-タイムアウト：30自信-しきい値：85
S->C:MRCP/1.0 543256 200 COMPLETE
S-> C：MRCP / 1.0 543256 200 COMPLETE
The GET-PARAMS method, from the client to the server, asks the recognizer resource for its current default parameters, like sensitivity-level, n-best-list-length, etc. The client can request specific parameters from the server by sending it one or more empty parameter headers with no values. The server should then return the settings for those specific parameters only. When the client does not send a specific list of empty parameter headers, the recognizer should return the settings for all parameters. The wild card use can be very intensive as the number of settable parameters can be large depending on the vendor. Hence, it is RECOMMENDED that the client does not use the wildcard GET-PARAMS operation very often.
GET-PARAMSメソッドは、クライアントからサーバに、クライアントはそれを送信することで、サーバから特定のパラメータを要求することができ、感度レベルのように、現在のデフォルトパラメータのためのnベストリストの長さなどを認識器リソースを要求しますなし値の一つ以上の空のパラメータヘッダ。その後、サーバーはのみ、特定のパラメータの設定を返す必要があります。クライアントが空のパラメータヘッダの特定のリストを送信しない場合は、認識装置は、すべてのパラメータの設定値を返す必要があります。設定可能なパラメータの数は、ベンダーに依存して大きくすることができるようにワイルドカードの使用が非常に集中することができます。したがって、クライアントが非常に頻繁にワイルドカードGET-PARAMS操作を使用しないことが推奨されます。
Example: C->S:GET-PARAMS 543256 MRCP/1.0 Sensitivity-Level: Recognition-Timeout: Confidence-threshold:
例：C-> S：GET-PARAMS 543256 MRCP / 1.0感度レベル：認識-タイムアウト：信頼しきい値：
S->C:MRCP/1.0 543256 200 COMPLETE Sensitivity-Level:20 Recognition-Timeout:30 Confidence-Threshold:85
S-> C：MRCP / 1.0 543256 200 COMPLETE感度レベル：20認識タイムアウト：30信頼-しきい値：85
The DEFINE-GRAMMAR method, from the client to the server, provides a grammar and tells the server to define, download if needed, and compile the grammar.
DEFINE - GRAMMARメソッドは、クライアントからサーバに、文法を提供し、定義し、必要に応じてダウンロードし、文法をコンパイルするためにサーバーに指示します。
If the server resource is in the recognition state, the DEFINE-GRAMMAR request MUST respond with a failure status.
サーバーリソースが認識状態にある場合は、DEFINE - GRAMMAR要求は失敗ステータスで応じなければなりません。
If the resource is in the idle state and is able to successfully load and compile the grammar, the status MUST return a success code and the request-state MUST be COMPLETE.
リソースがアイドル状態にあり、正常にロードし、文法をコンパイルすることがある場合は、ステータスが完了していなければならない成功コードと要求状態を返さなければなりません。
If the recognizer could not define the grammar for some reason, say the download failed or the grammar failed to compile, or the grammar was in an unsupported form, the MRCP response for the DEFINE-GRAMMAR method MUST contain a failure status code of 407, and a completion-cause header field describing the failure reason.
認識装置が何らかの理由で文法を定義することができなかった場合は、ダウンロードが失敗したか、文法がコンパイルに失敗したか、または文法がサポートされていない形でだったと言う、DEFINE - GRAMMARメソッドのMRCP応答は、407エラー状態コードを含まなければなりません完了原因ヘッダフィールドは、失敗の理由を説明します。
Example: C->S:DEFINE-GRAMMAR 543257 MRCP/1.0 Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104
例：C-> S：DEFINE文法543257 MRCP / 1.0コンテンツタイプ：アプリケーション/文法+ XMLコンテンツID：request1@form-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
<！ - トークンに単一の言語の添付ファイル - > <ルールID = "はい"> <1-の> <項目のXML：LANG = "FR-CA"> OUI </ item>の<アイテムのXML：LANG = "EN -US ">はい</ item>の</> </ルール1-の>
<!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私はに話すことがあり、<1-のXML：LANG = "FR-CA"> <項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
</grammar>
</文法>
S->C:MRCP/1.0 543257 200 COMPLETE Completion-Cause:000 success
S-> C：MRCP / 1.0 543257 200 COMPLETE完了-原因：000成功
C->S:DEFINE-GRAMMAR 543258 MRCP/1.0 Content-Type:application/grammar+xml Content-Id:helpgrammar@root-level.store Content-Length:104
C-> S：DEFINE文法543258 MRCP / 1.0のContent-Type：アプリケーション/文法+ xmlのコンテンツID：helpgrammar@root-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<rule id="request"> I need help </rule>
<ルールID = "要求">私は助けを必要とする</ルール>
</grammar>
</文法>
S->C:MRCP/1.0 543258 200 COMPLETE Completion-Cause:000 success
S-> C：MRCP / 1.0 543258 200 COMPLETE完了-原因：000成功
C->S:DEFINE-GRAMMAR 543259 MRCP/1.0 Content-Type:application/grammar+xml Content-Id:request2@field-level.store Content-Length:104 <?xml version="1.0"?>
C-> S：アプリケーション/文法+ XMLのContent-ID：543259 MRCP / 1.0 Content-Typeの文法を定義request2@field-level.storeのContent-Length：？？104 <XMLバージョンを= "1.0">
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<rule id="request"> I need help </rule>
<ルールID = "要求">私は助けを必要とする</ルール>
S->C:MRCP/1.0 543258 200 COMPLETE
S-> C：MRCP / 1.0 543258 200 COMPLETE
Completion-Cause:000 success
完成-原因：000成功
C->S:DEFINE-GRAMMAR 543259 MRCP/1.0 Content-Type:application/grammar+xml Content-Id:request2@field-level.store Content-Length:104
C-> S：DEFINE文法543259 MRCP / 1.0のContent-Type：アプリケーション/文法+ xmlのコンテンツID：request2@field-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<grammar xml:lang="en">
<文法のXML：LANG = "EN">
<import uri="session:politeness@form-level.store" name="polite"/>
<輸入URI = "セッション：politeness@form-level.store" 名前= "礼儀正しいです" />
<rule id="basicCmd" scope="public"> <example> please move the window </example> <example> open a file </example>
<ルールID = "basicCmd" スコープ= "公共"> <例>ウィンドウ</例> <例>ファイルを開く</例>を移動してください
<ruleref import="polite#startPolite"/> <ruleref uri="#command"/> <ruleref import="polite#endPolite"/> </rule>
<rulerefインポート= "丁寧＃startPolite" /> <ruleref URI = "＃コマンド" /> <rulerefインポート= "丁寧＃のendPolite" /> </ルール>
<rule id="command"> <ruleref uri="#action"/> <ruleref uri="#object"/> </rule>
<ルールID = "コマンド"> <ruleref URI = "＃アクション" /> <ruleref URI = "＃オブジェクト" /> </ルール>
<rule id="action"> <choice> <item weight="10" tag="OPEN"> open </item> <item weight="2" tag="CLOSE"> close </item> <item weight="1" tag="DELETE"> delete </item> <item weight="1" tag="MOVE"> move </item> </choice> </rule>
<ルールID = "アクション"> <選択> <項目重量= "10" タグ= "OPEN"> </商品> <商品重量= "CLOSE" = "2" タグ>開く</商品> <商品重量近いです= "1" タグ= "削除"> </商品> <商品重量= "1" タグ= "MOVE">移動</商品> </選択> </ルール>削除
<rule id="object"> <count number="optional"> <choice> <item> the </item> <item> a </item> </choice> </count> <choice> <item> window </item> <item> file </item> <item> menu </item> </choice>
<ルールID = "オブジェクト"> <カウント数= "オプション"> <選択>の<item> </商品> <商品> </商品> </選択> </カウント> <選択>の<item>ウィンドウ</ item>は<item>のファイル</ item>の<項目>メニュー</ item>の</選択>
</rule>
</ルール>
</grammar>
</文法>
S->C:MRCP/1.0 543259 200 COMPLETE Completion-Cause:000 success
S-> C：MRCP / 1.0 543259 200 COMPLETE完了-原因：000成功
C->S:RECOGNIZE 543260 MRCP/1.0 N-Best-List-Length:2 Content-Type:text/uri-list Content-Length:176
C-> S：543260 MRCP / 1.0 N-ベスト・リスト長を認識：2のContent-Type：uriテキスト/リストのContent-Length：176
session:request1@form-level.store
session:request2@field-level.store
session:helpgramar@root-level.store
S->C:MRCP/1.0 543260 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543260 200
S->C:START-OF-SPEECH 543260 IN-PROGRESS MRCP/1.0
S-> C：START-OF-SPEECH 543260 IN-PROGRESS MRCP / 1.0
S->C:RECOGNITION-COMPLETE 543260 COMPLETE MRCP/1.0 Completion-Cause:000 success Waveform-URL:http://web.media.com/session123/audio.wav Content-Type:applicationt/x-nlsml Content-Length:276
S-> C：認識-COMPLETE 543260 COMPLETE MRCP / 1.0完成-原因：000成功波形-URL：のhttp：//web.media.com/session123/audio.wavのコンテンツタイプ：applicationt / X-nlsmlのContent-Length ：276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
The RECOGNIZE method from the client to the server tells the recognizer to start recognition and provides it with a grammar to match for. The RECOGNIZE method can carry parameters to control the sensitivity, confidence level, and the level of detail in results provided by the recognizer. These parameters override the current defaults set by a previous SET-PARAMS method.
クライアントからサーバにする方法を認識認識を開始するために、認識を告げるとするために一致するように、文法とそれを提供します。 RECOGNIZE方法は、感度、信頼水準、及び認識によって提供される結果の詳細レベルを制御するためのパラメータを搬送することができます。これらのパラメータは、以前のSET-PARAMSメソッドによって設定された現在のデフォルト値を上書きします。
If the resource is in the recognition state, the RECOGNIZE request MUST respond with a failure status.
リソースは認識状態にある場合は、障害状態で応答しなければならない要求を認識しています。
If the resource is in the Idle state and was able to successfully start the recognition, the server MUST return a success code and a request-state of IN-PROGRESS. This means that the recognizer is active and that the client should expect further events with this request-id.
リソースがアイドル状態にあり、正常に認識を開始することができた場合は、サーバーは成功コードとIN-PROGRESSの要求状態を返さなければなりません。これは、認識がアクティブであることと、クライアントはこの要求-idで、さらにイベントを期待するべきであることを意味します。
If the resource could not start a recognition, it MUST return a failure status code of 407 and contain a completion-cause header field describing the cause of failure.
リソースが認識を開始することができなかった場合、それは407のエラーステータスコードを返し、失敗の原因を説明する完了原因のヘッダフィールドを含まなければなりません。
For the recognizer resource, this is the only request that can return request-state of IN-PROGRESS, meaning that recognition is in progress. When the recognition completes by matching one of the grammar alternatives or by a time-out without a match or for some other reason, the recognizer resource MUST send the client a RECOGNITON-COMPLETE event with the result of the recognition and a request-state of COMPLETE.
認識器リソースの場合、これは認識が進行中であることを意味し、IN-PROGRESSの要求状態を返すことができる唯一の要求です。認識が一致せず、または他のいくつかの理由で文法の選択肢の一つまたはタイムアウトによりを照合することによって完了すると、認識器リソースは、認識との要求状態の結果をクライアントにRECOGNITON-COMPLETEイベントを送らなければなりませんコンプリート。
For large grammars that can take a long time to compile and for grammars that are used repeatedly, the client could issue a DEFINE-GRAMMAR request with the grammar ahead of time. In such a case, the client can issue the RECOGNIZE request and reference the grammar through the "session:" special URI. This also applies in general if the client wants to restart recognition with a previous inline grammar.
コンパイルするのに長い時間がかかることが大きな文法のために繰り返し使用されている文法のために、クライアントは、事前に文法とDEFINE - GRAMMAR要求を発行することができます。そのような場合には、クライアントを認識リクエストを発行することができますし、「セッション：」を通じて文法を参照する特別なURI。クライアントが以前のインライン文法との認識を再起動したい場合にも、一般的に適用されます。
Note that since the audio and the messages are carried over separate communication paths there may be a race condition between the start of the flow of audio and the receipt of the RECOGNIZE method. For example, if audio flow is started by the client at the same time as the RECOGNIZE method is sent, either the audio or the RECOGNIZE will arrive at the recognizer first. As another example, the client may chose to continuously send audio to the Media server and signal the Media server to recognize using the RECOGNIZE method. A number of mechanisms exist to resolve this condition and the mechanism chosen is left to the implementers of recognizer Media servers.
オーディオ及びメッセージは別個の通信パスを介して搬送されているので、オーディオの流れの開始及びRECOGNIZE方式の受信との間の競合状態が存在し得ることに留意されたいです。オーディオの流れが認識法と同時に、クライアントによって開始された場合、オーディオまたは最初の認識装置に到着するRECOGNIZEのいずれかに送信されます。別の例として、クライアントが継続的にメディアサーバーにオーディオを送信し、方法を認識し使用して認識するためにメディアをサーバーに指示することを選択することができます。メカニズムの数は、この状態を解決するために存在し、選択されたメカニズムは、認識のメディアサーバの実装に任されています。
Example: C->S:RECOGNIZE 543257 MRCP/1.0 Confidence-Threshold:90 Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104
例：C-> S：543257 MRCP / 1.0信頼-しきい値を認識：90コンテンツタイプ：アプリケーション/文法+ XMLコンテンツ-ID：request1@form-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
<！ - トークンに単一の言語の添付ファイル - > <ルールID = "はい"> <1-の> <項目のXML：LANG = "FR-CA"> OUI </ item>の<アイテムのXML：LANG = "EN -US ">はい</ item>の</> </ルール1-の>
<!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私はに話すことがあり、<1-のXML：LANG = "FR-CA"> <項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
</grammar>
</文法>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543257 200
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S-> C：START-OF-SPEECH 543257 IN-PROGRESS MRCP / 1.0
S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0
S-> C：認識-COMPLETE 543257 COMPLETE MRCP / 1.0
Completion-Cause:000 success
Waveform-URL:http://web.media.com/session123/audio.wav
Content-Type:application/x-nlsml
Content-Length:276
<?xml version="1.0"?> <result x-model="http://IdentityModel" xmlns:xf="http://www.w3.org/2000/xforms" grammar="session:request1@form-level.store"> <interpretation> <xf:instance name="Person"> <Person> <Name> Andre Roy </Name> </Person> </xf:instance> <input> may I speak to Andre Roy </input> </interpretation> </result>
<？xml version = "1.0"？> <結果X-モデル= "のhttp：// IdentityModel" のxmlns：XF = "http://www.w3.org/2000/xforms" 文法= "セッション：request1の@フォーム-level.store "> <解釈> <XF：インスタンス名=" 人 "> <人> <名前>アンドレ・ロイ</名前> </人> </ XF：インスタンス> <入力>は、私はアンドレ・ロイに話すこと</入力> </通訳> </結果>
The STOP method from the client to the server tells the resource to stop recognition if one is active. If a RECOGNIZE request is active and the STOP request successfully terminated it, then the response header contains an active-request-id-list header field containing the request-id of the RECOGNIZE request that was terminated. In this case, no RECOGNITION-COMPLETE event will be sent for the terminated request. If there was no recognition active, then the response MUST NOT contain an active-request-id-list header field. Either way,method the response MUST contain a status of 200(Success).
クライアントからサーバーへのSTOPメソッドは1つがアクティブであるかどうかの認識を停止するためにリソースを伝えます。要求を認識した場合はアクティブで、STOP要求が正常に終了し、その後、応答ヘッダが終了したRECOGNIZEリクエストのリクエストIDを含むアクティブ要求IDリストヘッダフィールドを含みます。この場合、認識なし-COMPLETEイベントは終了要求に対して送信されません。活性NO認識がなかった場合、応答は、アクティブ要求IDリストヘッダフィールドを含んではなりません。いずれにせよ、この方法応答が200（成功）のステータスを含まなければなりません。
Example: C->S:RECOGNIZE 543257 MRCP/1.0 Confidence-Threshold:90 Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104
例：C-> S：543257 MRCP / 1.0信頼-しきい値を認識：90コンテンツタイプ：アプリケーション/文法+ XMLコンテンツ-ID：request1@form-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
<！ - トークンに単一の言語の添付ファイル - > <ルールID = "はい"> <1-の> <項目のXML：LANG = "FR-CA"> OUI </ item>の<アイテムのXML：LANG = "EN -US ">はい</ item>の</> </ルール1-の>
<!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私はに話すことがあり、<1-のXML：LANG = "FR-CA"> <項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
</grammar>
</文法>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543257 200
C->S:STOP 543258 200 MRCP/1.0
C-> S：STOP 543258 200 MRCP / 1.0
S->C:MRCP/1.0 543258 200 COMPLETE Active-Request-Id-List:543257
S-> C：MRCP / 1.0 543258 200 COMPLETEアクティブ要求-ID-リスト：543257
The GET-RESULT method from the client to the server can be issued when the recognizer is in the recognized state. This request allows the client to retrieve results for a completed recognition. This is useful if the client decides it wants more alternatives or more information. When the media server receives this request, it should re-compute and return the results according to the recognition constraints provided in the GET-RESULT request.
認識装置が認識状態にあるときに、クライアントからサーバへのGET-RESULTメソッドを発行することができます。この要求は、クライアントが完了した認識の結果を取得することができます。クライアントは、それがより多くの選択肢以上の情報を望んでいることを決定した場合に便利です。メディアサーバーがこの要求を受信すると、再計算し、GET-RESULT要求で提供された認識制約に応じて結果を返す必要があります。
The GET-RESULT request could specify constraints like a different confidence-threshold, or n-best-list-length. This feature is optional and the automatic speech recognition (ASR) engine may return a status of unsupported feature.
GET-RESULT要求が異なる自信しきい値、またはnベストリストの長さなどの制約を指定することができます。この機能はオプションであり、自動音声認識（ASR）エンジンがサポートされていない機能のステータスを返すことができます。
Example: C->S:GET-RESULT 543257 MRCP/1.0 Confidence-Threshold:90
例：C-> S：GET-RESULT 543257 MRCP / 1.0信頼-しきい値：90
S->C:MRCP/1.0 543257 200 COMPLETE Content-Type:application/x-nlsml Content-Length:276
S-> C：MRCP / 1.0 543257 200 COMPLETEコンテンツタイプ：アプリケーション/ X-nlsmlのContent-Length：276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person> </xf:instance> <input> may I speak to Andre Roy </input> </interpretation> </result>
</人> </ XF：インスタンス>の<input>私はアンドレ・ロイに話すこと</入力> </通訳> </結果>
This is an event from the recognizer to the client indicating that it has detected speech. This event is useful in implementing kill-on-barge-in scenarios when the synthesizer resource is in a different session than the recognizer resource and, hence, is not aware of an incoming audio source. In these cases, it is up to the client to act as a proxy and turn around and issue the BARGE-IN-OCCURRED method to the synthesizer resource. The recognizer resource also sends a unique proxy-sync-id in the header for this event, which is sent to the synthesizer in the BARGE-IN-OCCURRED method to the synthesizer.
これは、スピーチを検出したことを示す認識装置からクライアントへのイベントです。このイベントは、シンセサイザーのリソースは、認識のリソースとは異なるセッションであり、従って、着信オーディオソースを認識していないときにキル・オン・バージ・インのシナリオを実装する際に便利です。このような場合は、プロキシとして動作し、振り向くとシンセサイザーのリソースにBARGE-IN-OCCURREDメソッドを発行するクライアント次第です。認識リソースはまた、合成のバージイン-OCCURRED方法でシンセサイザに送信され、このイベントのヘッダ内の一意のプロキシ同期-IDを送信します。
This event should be generated irrespective of whether the synthesizer and recognizer are in the same media server or not.
このイベントは関係なく、シンセサイザーと認識装置は、同じメディアサーバーであるか否かの生成する必要があります。
This request is sent from the client to the recognition resource when it knows that a kill-on-barge-in prompt has finished playing. This is useful in the scenario when the recognition and synthesizer engines are not in the same session. Here, when a kill-on-barge-in prompt is being played, you want the RECOGNIZE request to be simultaneously active so that it can detect and implement kill-on-barge-in. But at the same time, you don't want the recognizer to start the no-input timers until the prompt is finished. The parameter recognizer-start-timers header field in the RECOGNIZE request will allow the client to say if the timers should be started or not. The recognizer should not start the timers until the client sends a RECOGNITION-START-TIMERS method to the recognizer.
それはキル・オン・バージ・インプロンプトの再生が終了したことを知っているときに、この要求は認識リソースにクライアントから送信されます。認識とシンセサイザーエンジンが同じセッションにない場合は、このシナリオで有用です。ここでは、キル・オン・バージ・インプロンプトが再生されているとき、あなたはそれがキル・オン・はしけインを検出し、実装することができるように同時にアクティブにすることを認識リクエストをしたいです。しかし同時に、プロンプトが終了するまで、認識が無入力のタイマーを起動する必要はありません。リクエストを認識におけるパラメータ認識装置・スタート・タイマーヘッダフィールドは、タイマーが起動するかどうクライアントが言うことができます。クライアントが認識装置に認識-START-TIMERS方法を送信するまで認識器はタイマを起動してはいけません。
This is an Event from the recognizer resource to the client indicating that the recognition completed. The recognition result is sent in the MRCP body of the message. The request-state field MUST be COMPLETE indicating that this is the last event with that request-id, and that the request with that request-id is now complete. The recognizer context still holds the results and the audio waveform input of that recognition until the next RECOGNIZE request is issued. A URL to the audio waveform MAY BE returned to the client in a waveform-url header field in the RECOGNITION-COMPLETE event. The client can use this URI to retrieve or playback the audio.
これは、認識が完了したことを示すクライアントへの認識器リソースからのイベントです。認識結果は、メッセージのMRCP本体に送信されます。要求ステートフィールドは、これがその要求IDを持つ最後のイベントであること、及びその要求IDを持つリクエストが今完了したことを示す完了していなければなりません。認識器コンテキストはまだRECOGNIZE次の要求が発行されるまでの結果とその認識のオーディオ波形の入力を保持しています。オーディオ波形のURLは認識COMPLETEイベントで波形-URLヘッダフィールドに、クライアントに返されることがあります。クライアントは、取得したり、オーディオを再生するために、このURIを使用することができます。
Example: C->S:RECOGNIZE 543257 MRCP/1.0 Confidence-Threshold:90 Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104
例：C-> S：543257 MRCP / 1.0信頼-しきい値を認識：90コンテンツタイプ：アプリケーション/文法+ XMLコンテンツ-ID：request1@form-level.storeのContent-Length：104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
<！ - トークンに単一の言語の添付ファイル - > <ルールID = "はい"> <1-の> <項目のXML：LANG = "FR-CA"> OUI </ item>の<アイテムのXML：LANG = "EN -US ">はい</ item>の</> </ルール1-の>
<!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私はに話すことがあり、<1-のXML：LANG = "FR-CA"> <項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
</grammar>
</文法>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S-> C：IN-PROGRESS MRCP / 1.0 543257 200
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S-> C：START-OF-SPEECH 543257 IN-PROGRESS MRCP / 1.0
S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0 Completion-Cause:000 success Waveform-URL:http://web.media.com/session123/audio.wav Content-Type:application/x-nlsml Content-Length:276
S-> C：認識-COMPLETE 543257 COMPLETE MRCP / 1.0完成-原因：000成功波形-URL：のhttp：//web.media.com/session123/audio.wavのコンテンツタイプ：アプリケーション/ X-nlsmlのContent-Length ：276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Digits received as DTMF tones will be delivered to the automatic speech recognition (ASR) engine in the RTP stream according to RFC 2833 [15]. The automatic speech recognizer (ASR) needs to support RFC 2833 [15] to recognize digits. If it does not support RFC 2833 [15], it will have to process the audio stream and extract the audio tones from it.
DTMFトーンは、RFC 2833 [15]に記載のRTPストリームに自動音声認識（ASR）エンジンに供給されるようにディジットを受信しました。自動音声認識（ASR）は、数字を認識するようにRFC 2833 [15]をサポートする必要があります。それはRFC 2833 [15]をサポートしていない場合は、オーディオストリームを処理する必要があり、そこからオーディオトーンを抽出します。
Various sections of the recognizer could be distributed into Digital Signal Processors (DSPs) on the Voice Browser/Gateway or IP Phones. For instance, the gateway might perform voice activity detection to reduce network bandwidth and CPU requirement of the automatic speech recognition (ASR) server. Such extensions are deferred for further study and will not be addressed in this document.
認識装置の様々なセクションでは、音声ブラウザ/ゲートウェイまたはIP Phoneでのデジタル信号プロセッサ（DSP）に分配することができます。例えば、ゲートウェイは、ネットワーク帯域幅と自動音声認識（ASR）サーバのCPU要件を低減するために、音声アクティビティ検出を実行するかもしれません。このような拡張は、さらなる研究のため延期されており、本書で扱われることはありません。
The MRCP protocol may carry sensitive information such as account numbers, passwords, etc. For this reason it is important that the client have the option of secure communication with the server for both the control messages as well as the media, though the client is not required to use it. If all MRCP communications happens in a trusted domain behind a firewall, this may not be necessary. If the client or server is deployed in an insecure network, communication happening across this insecure network needs to be protected. In such cases, the following additional security functionality MUST be supported on the MRCP server. MRCP servers MUST implement Transport Layer Security (TLS) to secure the RTSP communication, i.e., the RTSP stack SHOULD support the rtsps: URI form. MRCP servers MUST support Secure Real-Time Transport Protocol (SRTP) as an option to send and receive media.
MRCPプロトコルは、このような理由から、クライアントがありませんが、クライアントは、両方の制御メッセージのためのサーバだけでなく、メディアとの安全な通信のオプションを持っていることが重要であるなど口座番号、パスワードなどの機密情報を運ぶことができますそれを使用するために必要。すべてのMRCP通信がファイアウォールの背後にある信頼されたドメインで発生した場合、これは必要ではないかもしれません。クライアントまたはサーバが安全でないネットワークに配置されている場合は、この安全でないネットワークを介して起こって通信を保護する必要があります。このような場合には、次の追加のセキュリティ機能は、MRCPサーバー上でサポートしなければなりません。 URI形式：MRCPサーバは、すなわち、RTSPスタックはRTSPSをサポートするべきで、RTSPの通信を確保するためにトランスポート層セキュリティ（TLS）を実装しなければなりません。 MRCPサーバは、メディアを送受信するためのオプションとして、セキュアリアルタイムトランスポートプロトコル（SRTP）をサポートしなければなりません。
The following is an example of a typical session of speech synthesis and recognition between a client and the server.
以下は、クライアントとサーバーの間で音声合成・認識の典型的なセッションの例です。
Opening the synthesizer. This is the first resource for this session. The server and client agree on a single Session ID 12345678 and set of RTP/RTCP ports on both sides.
シンセサイザーを開きます。これは、このセッションの最初のリソースです。サーバとクライアントは、単一のセッションID 12345678に同意し、両側のRTP / RTCPポートのセット。
C->S:SETUP rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:2 Transport:RTP/AVP;unicast;client_port=46456-46457 Content-Type:application/sdp
C-> S：SETUPのRTSP：//media.server.com/media/synthesizer RTSP / 1.0のCSeq：2トランスポート：RTP / AVP;ユニキャスト; CLIENT_PORT = 46456から46457コンテンツタイプ：アプリケーション/ SDP
Content-Length:190
コンテンツの長さ：190
v=0 o=- 123 456 IN IP4 10.0.0.1 s=Media Server p=+1-888-555-1212 c=IN IP4 0.0.0.0 t=0 0 m=audio 0 RTP/AVP 0 96 a=rtpmap:0 pcmu/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15
V = 0 0 = - 123 456 IP4 IN 10.0.0.1 S =メディアサーバP = + 1-888-555-1212 C = IP4 0.0.0.0 IN T = 0、M = 0オーディオRTP / AVP 0 96 = rtpmap ：0 PCMU / 8000 = rtpmap：96電話イベント/ 8000 =のfmtp：96 0~15
S->C:RTSP/1.0 200 OK CSeq:2 Transport:RTP/AVP;unicast;client_port=46456-46457; server_port=46460-46461 Session:12345678 Content-Length:190 Content-Type:application/sdp
S-> C：RTSP / 1.0 200 OKのCSeq：2トランスポート：RTP / AVP;ユニキャスト; CLIENT_PORT = 46456から46457。 SERVER_PORT = 46460から46461セッション：12345678のContent-Length：190のContent-Type：アプリケーション/ SDP
v=0
o=- 3211724219 3211724219 IN IP4 10.3.2.88
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
m=audio 46460 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
Opening a recognizer resource. Uses the existing session ID and ports.
認識器リソースを開きます。既存のセッションIDとポートを使用します。
C->S:SETUP rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:3 Transport:RTP/AVP;unicast;client_port=46456-46457; mode=record;ttl=127 Session:12345678
C-> S：SETUPのRTSP：//media.server.com/media/recognizer RTSP / 1.0のCSeq：3トランスポート：RTP / AVP;ユニキャスト; CLIENT_PORT = 46456から46457。モード=記録; TTL = 127セッション：12345678
S->C:RTSP/1.0 200 OK CSeq:3 Transport:RTP/AVP;unicast;client_port=46456-46457; server_port=46460-46461;mode=record;ttl=127 Session:12345678
S-> C：RTSP / 1.0 200 OKのCSeq：3トランスポート：RTP / AVP;ユニキャスト; CLIENT_PORT = 46456から46457。 SERVER_PORT = 46460から46461;モード=記録; TTL = 127セッション：12345678
An ANNOUNCE message with the MRCP SPEAK request initiates speech.
MRCPのSPEAK要求にアナウンスメッセージは、音声を開始します。
C->S:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:4 Session:12345678 Content-Type:application/mrcp Content-Length:456
C-> S：RTSPを発表：4セッション：12345678のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：456 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
SPEAK 543257 MRCP/1.0
Kill-On-Barge-In:false
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
<?xml version="1.0"?> <speak> <paragraph> <sentence>You have 4 new messages.</sentence> <sentence>The first is from <say-as type="name">Stephanie Williams</say-as> <mark name="Stephanie"/> and arrived at <break/> <say-as type="time">3:45pm</say-as>.</sentence>
<？xml version = "1.0"？> <話す> <パラグラフ> <文>あなたは4件の新しいメッセージがあります。最初から</文> <文>は<言う-としてタイプ= "名前">ステファニー・ウィリアムズ</ > <マーク名= "ステファニー" />として-言うと<> <言う-ようなタイプ= "時間" />破る15:45 </言う-よう>に到着しました。</文>
<sentence>The subject is <prosody rate="-20%">ski trip</prosody></sentence> </paragraph> </speak>
<文>件名は< " - 20％" 韻律率=>はスキー旅行</韻律> </文> </パラグラフ> </話します>
S->C:RTSP/1.0 200 OK CSeq:4 Session:12345678 RTP-Info:url=rtsp://media.server.com/media/synthesizer; seq=9810092;rtptime=3450012 Content-Type:application/mrcp Content-Length:456
S-> C：RTSP / 1.0 200 OKのCSeq：4セッション：12345678 RTP-情報：URL = RTSP：//media.server.com/media/synthesizer。 SEQ = 9810092; rtptime = 3450012のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：456
MRCP/1.0 543257 200 IN-PROGRESS
IN-PROGRESS MRCP / 1.0 543257 200
The synthesizer hits the special marker in the message to be spoken and faithfully informs the client of the event.
シンセサイザは話さ忠実イベントのクライアントに通知するメッセージで特殊なマーカーを打ちます。
S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:5 Session:12345678
S-> C：RTSPを発表：5セッション：12345678 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
Content-Type:application/mrcp
Content-Length:123
SPEECH-MARKER 543257 IN-PROGRESS MRCP/1.0 Speech-Marker:Stephanie C->S:RTSP/1.0 200 OK CSeq:5
SPEECH - MARKER 543257 IN-PROGRESS MRCP / 1.0スピーチ-マーカー：ステファニーC-> S：RTSP / 1.0 200 OKのCSeq：5
The synthesizer finishes with the SPEAK request.
シンセサイザーは、SPEAK要求で終了します。
S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:6 Session:12345678 Content-Type:application/mrcp Content-Length:123
S-> C：RTSPを発表：6セッション：12345678のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：123 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0
SPEAK-COMPLETE 543257 COMPLETE MRCP / 1.0
C->S:RTSP/1.0 200 OK CSeq:6
C-> S：RTSP / 1.0 200 OKのCSeq：6
The recognizer is issued a request to listen for the customer choices.
認識装置は、顧客の選択肢をリッスンする要求を発行しています。
C->S:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:7 Session:12345678
C-> S：RTSPを発表：7セッション：12345678 RTSP / 1.0のCSeq //media.server.com/media/recognizer
RECOGNIZE 543258 MRCP/1.0
Content-Type:application/grammar+xml
Content-Length:104
<?xml version="1.0"?>
<？xml version = "1.0"？>
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<！ - デフォルトの文法の言語は英語（米国）である - > <文法のXML：LANG = "EN-US" バージョン= "1.0">
<!-- single language attachment to a rule expansion --> <rule id="request"> Can I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule>
<！ - ルールの展開に単一の言語の添付ファイル - > <ルールID = "要求">私は<1-のXML：LANG = "FR-CA">に話すことができます。<項目>マイケル・トレンブレイ</ item>の<アイテム>アンドレ・ロイ</ item>の</> </ルール1-の>
</grammar>
</文法>
S->C:RTSP/1.0 200 OK CSeq:7 Content-Type:application/mrcp Content-Length:123
S-> C：RTSP / 1.0 200 OKのCSeq：7コンテンツタイプ：アプリケーション/ MRCPのコンテンツ長：123
MRCP/1.0 543258 200 IN-PROGRESS
IN-PROGRESS MRCP / 1.0 543258 200
The client issues the next MRCP SPEAK method in an ANNOUNCE message, asking the user the question. It is generally RECOMMENDED when playing a prompt to the user with kill-on-barge-in and asking for input, that the client issue the RECOGNIZE request ahead of the SPEAK request for optimum performance and user experience. This way, it is guaranteed that the recognizer is online before the prompt starts playing and the user's speech will not be truncated at the beginning (especially for power users).
クライアントは、ユーザーに質問をして、アナウンスメッセージの次のMRCPのSPEAK方法を発行します。キル・オン・バージ・インして、ユーザーにプロンプトを再生し、入力を求めるときには、一般的にクライアントの問題が先に最適なパフォーマンスとユーザーエクスペリエンスのためのSPEAK要求の要求を認識することが、推奨されます。このように、プロンプトが再生を開始すると、ユーザの発話は、（特にパワーユーザーのための）先頭に切り捨てられないであろう前に、認識がオンラインであることが保証されています。
C->S:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:8 Session:12345678 Content-Type:application/mrcp Content-Length:733
C-> S：RTSPを発表：8セッション：12345678のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：733 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
SPEAK 543259 MRCP/1.0
Kill-On-Barge-In:true
Content-Type:application/synthesis+ssml
Content-Length:104
<?xml version="1.0"?> <speak> <paragraph> <sentence>Welcome to ABC corporation.</sentence> <sentence>Who would you like Talk to.</sentence> </paragraph> </speak>
ABC社に<？xmlのバージョン= "1.0"？> <話す> <パラグラフ> <文>ようこそ。</文> <文>あなたがに話したいと思います。</文> </パラグラフ> </話します>
S->C:RTSP/1.0 200 OK CSeq:8 Content-Type:application/mrcp Content-Length:123
S-> C：RTSP / 1.0 200 OKのCSeq：8コンテンツタイプ：アプリケーション/ MRCPのコンテンツ長：123
MRCP/1.0 543259 200 IN-PROGRESS
IN-PROGRESS MRCP / 1.0 543259 200
Since the last SPEAK request had Kill-On-Barge-In set to "true", the message synthesizer is interrupted when the user starts speaking, and the client is notified.
最後のSPEAK要求はキル・オン・バージ・インが「真」に設定されていたので、ユーザーが話し起動時にメッセージシンセサイザが中断され、クライアントに通知されます。
Now, since the recognition and synthesizer resources are in the same session, they worked with each other to deliver kill-on-barge-in. If the resources were in different sessions, it would have taken a few more messages before the client got the SPEAK-COMPLETE event from the synthesizer resource. Whether the synthesizer and recognizer are in the same session or not, the recognizer MUST generate the START-OF-SPEECH event to the client.
認識とシンセサイザーのリソースが同じセッションであるため、今、彼らはキル・オン・はしけインを提供するために、相互に働きました。リソースが異なるセッションにあった場合、クライアントは、シンセサイザリソースからSPEAK-COMPLETEイベントを得た前に、それはさらにいくつかのメッセージがかかったでしょう。シンセサイザーと認識装置は、同じセッションであるかどうかは、認識装置は、クライアントにSTART-OF-SPEECHイベントを発生させなければなりません。
The client should have then blindly turned around and issued a BARGE-IN-OCCURRED method to the synthesizer resource. The synthesizer, if kill-on-barge-in was enabled on the current SPEAK request, would have then interrupted it and issued SPEAK-COMPLETE event to the client. In this example, since the synthesizer and recognizer are in the same session, the client did not issue the BARGE-IN-OCCURRED method to the synthesizer and assumed that kill-on-barge-in was implemented between the two resources in the same session and worked.
次に、クライアントは盲目的に振り向くと、シンセサイザーのリソースにBARGE-IN-OCCURREDメソッドを発行している必要があります。キル・オン・バージ・インは、現在のSPEAK要求で有効になっていた場合シンセサイザは、それを中断して、クライアントにSPEAK-COMPLETEイベントを発行しているだろう。シンセサイザーと認識装置は、同じセッションであるため、この例では、クライアントは、シンセサイザにBARGE-IN-OCCURREDメソッドを発行し、キル・オン・バージ・インは、同じセッションで2つのリソースの間で実施されたことを想定していませんでしたそして、働きました。
The completion-cause code differentiates if this is normal completion or a kill-on-barge-in interruption.
これが正常終了またはキル・オン・バージ・インが中断された場合に完了原因コードが区別されます。
S->C:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:9 Session:12345678 Content-Type:application/mrcp Content-Length:273
S-> C：RTSPを発表：9セッション：12345678のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：273 RTSP / 1.0のCSeq //media.server.com/media/recognizer
START-OF-SPEECH 543258 IN-PROGRESS MRCP/1.0
START-OF-SPEECH IN-PROGRESS MRCP / 1.0 543258
C->S:RTSP/1.0 200 OK CSeq:9
C-> S：RTSP / 1.0 200 OKのCSeq：9
S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:10 Session:12345678 Content-Type:application/mrcp Content-Length:273
S-> C：RTSPを発表：10セッション：12345678のContent-Type：アプリケーション/ MRCPのコンテンツの長さ：273 RTSP / 1.0のCSeq //media.server.com/media/synthesizer
SPEAK-COMPLETE 543259 COMPLETE MRCP/1.0
Completion-Cause:000 normal
C->S:RTSP/1.0 200 OK CSeq:10
C-> S：RTSP / 1.0 200 OKのCSeq：10
The recognition resource matched the spoken stream to a grammar and generated results. The result of the recognition is returned by the server as part of the RECOGNITION-COMPLETE event.
認識リソースは、文法に話の流れにマッチし、結果を生成しました。認識結果は、認識COMPLETEイベントの一環として、サーバーによって返されます。
S->C:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:11 Session:12345678 Content-Type:application/mrcp
S-> C：RTSPを発表：11セッション：12345678のContent-Type：アプリケーション/ MRCP RTSP / 1.0のCSeq //media.server.com/media/recognizer
Content-Length:733
コンテンツの長さ：733
RECOGNITION-COMPLETE 543258 COMPLETE MRCP/1.0 Completion-Cause:000 success Waveform-URL:http://web.media.com/session123/audio.wav Content-Type:application/x-nlsml Content-Length:104
RECOGNITION-COMPLETE 543258 COMPLETE MRCP / 1.0完成-原因：000成功波形-URL：のhttp：//web.media.com/session123/audio.wavのコンテンツタイプ：アプリケーション/ X-nlsmlのContent-Length：104
<?xml version="1.0"?> <result x-model="http://IdentityModel" xmlns:xf="http://www.w3.org/2000/xforms" grammar="session:request1@form-level.store"> <interpretation> <xf:instance name="Person"> <Person> <Name> Andre Roy </Name> </Person> </xf:instance> <input> may I speak to Andre Roy </input> </interpretation> </result>
<？xml version = "1.0"？> <結果X-モデル= "のhttp：// IdentityModel" のxmlns：XF = "http://www.w3.org/2000/xforms" 文法= "セッション：request1の@フォーム-level.store "> <解釈> <XF：インスタンス名=" 人 "> <人> <名前>アンドレ・ロイ</名前> </人> </ XF：インスタンス> <入力>は、私はアンドレ・ロイに話すこと</入力> </通訳> </結果>
C->S:RTSP/1.0 200 OK CSeq:11
C-> S：RTSP / 1.0 200 OKのCSeq：11
C->S:TEARDOWN rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:12 Session:12345678
C-> S：TEARDOWNのRTSP：//media.server.com/media/synthesizer RTSP / 1.0のCSeq：12セッション：12345678
S->C:RTSP/1.0 200 OK CSeq:12
S-> C：RTSP / 1.0 200 OKのCSeq：12
We are done with the resources and are tearing them down. When the last of the resources for this session are released, the Session-ID and the RTP/RTCP ports are also released.
私たちは、リソースで行われており、それらを切断されています。このセッションのためのリソースの最後がリリースされると、セッションIDおよびRTP / RTCPポートも解放されます。
C->S:TEARDOWN rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:13 Session:12345678
C-> S：TEARDOWNのRTSP：//media.server.com/media/recognizer RTSP / 1.0のCSeq：13セッション：12345678
S->C:RTSP/1.0 200 OK CSeq:13
S-> C：RTSP / 1.0 200 OKのCSeq：13
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk. H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC 2616, June 1999.
[1]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk。 H.、Masinter、L.、リーチ、P.、およびT.バーナーズ=リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616、1999年6月。
[2] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998
[2] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] World Wide Web Consortium, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Candidate Recommendation, March 2004.
[6]ワールド・ワイド・ウェブ・コンソーシアム、 "ボイス拡張マークアップ言語（VoiceXMLの）バージョン2.0"、W3C勧告候補、2004年3月。
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[7]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[9] World Wide Web Consortium, "Speech Synthesis Markup Language (SSML) Version 1.0", W3C Candidate Recommendation, September 2004.
[9]ワールド・ワイド・ウェブ・コンソーシアム、 "音声合成マークアップ言語（SSML）バージョン1.0"、W3C勧告候補、2004年9月。
[10] World Wide Web Consortium, "Natural Language Semantics Markup Language (NLSML) for the Speech Interface Framework", W3C Working Draft, 30 May 2001.
[10]ワールド・ワイド・ウェブ・コンソーシアム、「音声インタフェースフレームワークのための自然言語の意味マークアップ言語（NLSML）」、W3Cワーキングドラフト2001年5月30日。
[11] World Wide Web Consortium, "Speech Recognition Grammar Specification Version 1.0", W3C Candidate Recommendation, March 2004.
[11]ワールド・ワイド・ウェブ・コンソーシアム、「音声認識文法仕様バージョン1.0」、W3C勧告候補、2004年3月。
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[12] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[13]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[14] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[14]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[15] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[15] Schulzrinneと、H.およびS. 2000 Petrackと、 "DTMFケタ、電話トーン、および電話信号のためのRTPペイロード"、RFC 2833、2000年5月。
[16] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[16] Alvestrand、H.、 "言語識別のためのタグ"、BCP 47、RFC 3066、2001年1月。
Appendix A. ABNF Message Definitions
付録A. ABNFメッセージ定義
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA =％x41-5A /％x61-7A。 -Z / Z-
CHAR = %x01-7F ; any 7-bit US-ASCII character, ; excluding NUL
CHAR =％x01-7F。すべての7ビットUS-ASCII文字、; NULを除きます
CR = %x0D ; carriage return
CR =％x0D。キャリッジリターン
CRLF = CR LF ; Internet standard newline
CRLF = CR LF。インターネット標準の改行
DIGIT = %x30-39 ; 0-9
DIGIT =％x30-39。 0-9
DQUOTE = %x22 ; " (Double Quote)
DQUOTE =％X22。 "（二重引用符）
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09 ; horizontal tab
HTAB =％X09。水平タブ
LF = %x0A ; linefeed
LF =％X0A。改行
OCTET = %x00-FF ; 8 bits of data
OCTET =％X00-FF。 8ビットのデータ
SP = %x20 ; space
SP =％のX20。スペース
WSP = SP / HTAB ; white space
WSP = SP / HTAB;ホワイトスペース
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
LWS = [WSP CRLF *] 1 * WSP。リニアの空白
SWS = [LWS] ; sep whitespace
SWS = [LWS]。 9月の空白
UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-NONASCII =％1UTF8-CONT XC0 DF / EF％xE0-2UTF8-CONT /％3UTF8 XF0-F7-CONT /％XF8 4UTF8-CONT-FB /％XFC-FD-CONT 5UTF8
UTF8-CONT = %x80-BF
UTF8-CONT =％X80-BF
param = *pchar
PARAM = *パブリシティ
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
引用符で囲んだ文字列= SWS DQUOTE *（qdtext /引用されたペア）DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
qdtext =トマト/％X21 /％x23-5B /％x5D-7E / UTF8-NONASCII
quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
引用されたペア= "\"（％x00-09 /％X0B-0C /％x0E-7F）
token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
トークン= 1 *（alphanum / " - " "" "！" / / / "％" / "*" / "_" / "+" / "`"/ "'"/ "〜"）
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
=予約 ";" / "/" / "？" / "：" / "@" / "＆" / "=" / "+" / "$" / ""
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
マーク= " - " / "_" / "" / "！" / "〜" / "*" / "'" / "（" / "）"
unreserved = alphanum / mark
予約されていない= alphanum /マーク
char = unreserved / escaped / ":" / "@" / "&" / "=" / "+" / "$" / ","
CHAR =予約されていない/エスケープ/ "：" / "@" / "＆" / "=" / "+" / "$" / ""
alphanum = ALPHA / DIGIT
alphanum = ALPHA / DIGIT
escaped = "%" HEXDIG HEXDIG
エスケープ= "％" HEXDIG HEXDIG
absoluteURI = scheme ":" ( hier-part / opaque-part )
absoluteURIで=スキーム "："（HIER部分/不透明部分）
relativeURI = ( net-path / abs-path / rel-path ) [ "?" query ]
relativeURI =（ネットパス/ ABS-パス/相対パス）[ "？"クエリ]
hier-part = ( net-path / abs-path ) [ "?" query ]
HIER部分=（ネットパス/ ABS-パス） "？"クエリ]
net-path = "//" authority [ abs-path ]
ネットパス= "//" 権威[ABS-パス]
abs-path = "/" path-segments
ABS-パス= "/" パスセグメント
rel-path = rel-segment [ abs-path ]
REL-パス= RELセグメント[絶対パス]
rel-segment = 1*( unreserved / escaped / ";" / "@" / "&" / "=" / "+" / "$" / "," )
REL-セグメントは= 1 *（予約されていない/エスケープ/ ";" / "@" / "＆" / "=" / "+" / "$" / ""）
opaque-part = uric-no-slash *uric
不透明な部分=尿-NO-スラッシュ*の尿
uric = reserved / unreserved / escaped
尿=予約/予約されていない/エスケープ
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
尿-NO-スラッシュ=予約されていない/エスケープ/ ";" / "？" / "：" / "@" / "＆" / "=" / "+" / "$" / ""
path-segments = segment *( "/" segment )
経路セグメント=セグメント*（「/」セグメント）
segment = *pchar *( ";" param ) scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
セグメント= * PChar型の*（ ";" PARAM）スキーム= ALPHA *（ALPHA / DIGIT / "+" / " - " / ""）
authority = srvr / reg-name
権威= SRVR / REG-名
srvr = [ [ userinfo "@" ] hostport ]
SRVR = [[userinfoを "@"]ホスト側]
reg-name = 1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / "&" / "=" / "+" )
REG-名= 1 *（予約されていない/エスケープ/ "$" / "" / ";" / "：" / "@" / "＆" / "=" / "+"）
query = *uric
クエリ= *尿
userinfo = ( user ) [ ":" password ] "@"
userinfo =（ユーザー）[ "：" パスワード] "@"
user = 1*( unreserved / escaped / user-unreserved )
ユーザー= 1 *（予約されていない/エスケープ/ユーザが予約されていません）
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
ユーザーが予約されていません= "＆" / "=" / "+" / "$" / "" / ";" / "？" / "/"
password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," )
パスワード= *（予約されていない/エスケープ/ "＆" / "=" / "+" / "$" / ""）
hostport = host [ ":" port ]
ホスト側=ホスト[ "：" ポート]
host = hostname / IPv4address / IPv6reference
ホスト=ホスト名/ IPv4Addressを/ IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
ホスト名= *（domainlabel ""）toplabelの[ "" ]
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
domainlabel = alphanum / alphanum *（alphanum / " - "）alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *（alphanum / " - "）alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
= 1 * 3DIGIT IPv4Addressを "" 1 * 3DIGIT "" 1 * 3DIGIT "" 1 * 3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
IPv6address = hexpart [ "：" IPv4Addressを]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexpart = hexseq / hexseq "::" [hexseq] / "::" [hexseq]
hexseq = hex4 *( ":" hex4)
hexseq = hex4 *（ "：" hex4）
hex4 = 1*4HEXDIG port = 1*DIGIT
hex4 = 1 * 4HEXDIGポート= 1 * DIGIT
generic-message = start-line message-header CRLF [ message-body ]
一般的なメッセージ=開始行のメッセージヘッダCRLF [メッセージ本体]
message-body = *OCTET
メッセージボディ= * OCTET
start-line = request-line / status-line / event-line
スタートライン=リクエストライン/ステータスライン/イベントライン
request-line = method-name SP request-id SP mrcp-version CRLF
リクエストライン=メソッド名SP要求-ID SPのMRCPバージョンCRLF
status-line = mrcp-version SP request-id SP status-code SP request-state CRLF
ステータスライン= MRCPバージョンのSP要求-ID SPステータスコードSP要求状態CRLF
event-line = event-name SP request-id SP request-state SP mrcp-version CRLF
イベントライン=イベント名SP要求-IDのSP要求状態SPのMRCPバージョンCRLF
message-header = 1*(generic-header / resource-header)
メッセージヘッダー= 1 *（ジェネリックヘッダ/リソースヘッダ）
generic-header = active-request-id-list / proxy-sync-id / content-id / content-type / content-length / content-base / content-location / content-encoding / cache-control / logging-tag ; -- content-id is as defined in RFC 2392 and RFC 2046
ジェネリックヘッダ=アクティブ要求IDリスト/プロキシシンクID /コンテンツID /コンテンツ・タイプ/コンテンツ長/コンテンツベース/コンテンツ位置/コンテンツ・エンコード/キャッシュ制御/ロギングタグ。 - コンテンツIDは、RFC 2392及びRFC 2046で定義されたように
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
MRCPバージョン= "MRCP" "/" 1 * DIGIT "" 1 * DIGIT
request-id = 1*DIGIT
リクエストID = 1 * DIGIT
status-code = 1*DIGIT
ステータスコード= 1 * DIGIT
active-request-id-list = "Active-Request-Id-List" ":" request-id *("," request-id) CRLF
アクティブ・リクエスト-ID-リスト= "アクティブ要求-ID-リスト" "：" 要求-ID *（ "" リクエスト-ID）CRLF
proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF
プロキシ同期-ID = "プロキシ同期-ID" "：" 1 * ALPHA CRLF
content-length = "Content-Length" ":" 1*DIGIT CRLF
コンテンツ長= "のContent-Length" "：" 1 * DIGIT CRLF
content-base = "Content-Base" ":" absoluteURI CRLF content-type = "Content-Type" ":" media-type
コンテンツ・ベース= "コンテンツベース" "：" absoluteURIでCRLFコンテンツタイプ= "Content-Typeの" "：" メディアタイプ
media-type = type "/" subtype *( ";" parameter )
メディアタイプ=タイプ「/」サブタイプ*（「;」パラメータ）
type = token
タイプ=トークン
subtype = token
サブタイプ=トークン
parameter = attribute "=" value
パラメータ=属性「=」値
attribute = token
属性=トークン
value = token / quoted-string
値=トークン/引用符で囲まれた文字列
content-encoding = "Content-Encoding" ":" *WSP content-coding *(*WSP "," *WSP content-coding *WSP ) CRLF
コンテンツエンコード= "コンテンツエンコード" "：" * WSPコンテンツコーディング*（* WSP "" * WSPコンテンツコーディング* WSP）CRLF
content-coding = token
コンテンツコーディング=トークン
content-location = "Content-Location" ":" ( absoluteURI / relativeURI ) CRLF
コンテンツの場所= "コンテンツロケーション" "："（absoluteURIで/ relativeURI）CRLF
cache-control = "Cache-Control" ":" *WSP cache-directive *( *WSP "," *WSP cache-directive *WSP ) CRLF
キャッシュ制御= "のCache-Control" "：" * WSPキャッシュ・ディレクティブ*（* WSP "" * WSPキャッシュ・ディレクティブ* WSP）CRLF
cache-directive = "max-age" "=" delta-seconds / "max-stale" "=" delta-seconds / "min-fresh" "=" delta-seconds
キャッシュ・ディレクティブ= "MAX-年齢" "=" デルタ秒/ "MAX-古い" "=" デルタ秒/ "MIN-新鮮" "=" デルタ - 秒
logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF
ロギングタグ=「ロギングタグ」「：」1 * ALPHA CRLF
resource-header = recognizer-header / synthesizer-header
リソースヘッダー=認識ヘッダ/シンセサイザーヘッダ
method-name = synthesizer-method / recognizer-method
メソッド名=シンセサイザー方式/認識装置、方法
event-name = synthesizer-event / recognizer-event
イベント名=シンセサイザーイベント/認識器イベント
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
要求状態= "COMPLETE" / "IN-PROGRESS" / "保留"
synthesizer-method = "SET-PARAMS" / "GET-PARAMS" / "SPEAK" / "STOP" / "PAUSE" / "RESUME" / "BARGE-IN-OCCURRED" / "CONTROL"
シンセサイザー-方法は= "SET-PARAMSを" / "GET-PARAMS" / "SPEAK" / "STOP" / "PAUSE" / "RESUME" / "BARGE-IN-発生しました" / "CONTROL"
synthesizer-event = "SPEECH-MARKER" / "SPEAK-COMPLETE"
シンセサイザー・イベント= "SPEECH-MARKER" / "SPEAK-COMPLETE"
synthesizer-header = jump-target / kill-on-barge-in / speaker-profile / completion-cause / voice-parameter / prosody-parameter / vendor-specific / speech-marker / speech-language / fetch-hint / audio-fetch-hint / fetch-timeout / failed-uri / failed-uri-cause / speak-restart / speak-length
シンセサイザー・ヘッダ=ジャンプ・ターゲット/殺す・オン・バージ・イン/スピーカープロファイル/完了原因/音声パラメータ/韻律パラメータ/ベンダー固有/音声マーカー/音声言語/フェッチヒント/オーディオ - フェッチ・ヒント/フェッチタイムアウト/失敗-URI /失敗-URI-原因/話す再起動/話す長
recognizer-method = "SET-PARAMS" / "GET-PARAMS" / "DEFINE-GRAMMAR" / "RECOGNIZE" / "GET-RESULT" / "RECOGNITION-START-TIMERS" / "STOP"
認識法= "SET-PARAMS" / "GET-PARAMS" / "を定義する文法" / "を認識" / "GET結果を" / "認識STARTタイマー" / "STOP"
recognizer-event = "START-OF-SPEECH" / "RECOGNITION-COMPLETE"
認識イベント= "START-OF-SPEECH" / "認識COMPLETE"
recognizer-header = confidence-threshold / sensitivity-level / speed-vs-accuracy / n-best-list-length
認識ヘッダー=信頼閾値/感度レベル/速度対精度/ Nベストリストの長さ
/ no-input-timeout
/ recognition-timeout
/ waveform-url
/ completion-cause
/ recognizer-context-block
/ recognizer-start-timers
/ vendor-specific
/ speech-complete-timeout
/ speech-incomplete-timeout
/ dtmf-interdigit-timeout
/ dtmf-term-timeout
/ dtmf-term-char
/ fetch-timeout
/ failed-uri
/ failed-uri-cause
/ save-waveform
/ new-audio-channel
/ speech-language
jump-target = "Jump-Size" ":" speech-length-value CRLF
ジャンプ・ターゲット=「「-サイズをジャンプ」：」発話長値CRLF
speech-length-value = numeric-speech-length / text-speech-length
発話長値=数値発話長/テキスト読み上げ長
text-speech-length = 1*ALPHA SP "Tag"
テキスト音声変換長= 1 * ALPHA SP「タグ」
numeric-speech-length =("+" / "-") 1*DIGIT SP numeric-speech-unit
数値スピーチ長=（「+」/「 - 」）1つの* DIGITのSP数値音声素片
numeric-speech-unit = "Second" / "Word" / "Sentence" / "Paragraph"
数値音声素片=「セカンド」/「言葉」/「文」/「段落」
delta-seconds = 1*DIGIT
デルタ秒= 1 * DIGIT
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF
殺すオンバージイン=「「オンバージインを殺す」：」ブール値CRLF
boolean-value = "true" / "false"
ブール値=「真」/「偽」
speaker-profile = "Speaker-Profile" ":" absoluteURI CRLF
スピーカー・プロフィール=「スピーカー・プロフィール」「：」absoluteURIでCRLF
completion-cause = "Completion-Cause" ":" 1*DIGIT SP 1*ALPHA CRLF
完了-原因= "完了-原因" "：" 1 * DIGITのSP 1 * ALPHA CRLF
voice-parameter = "Voice-" voice-param-name ":" voice-param-value CRLF
音声パラメータ= "Voice-" 音声のparam-名 "：" 音声のparam-値CRLF
voice-param-name = 1*ALPHA
音声のparam-名= 1 * ALPHA
voice-param-value = 1*alphanum
音声のparam-値= 1 *のalphanum
prosody-parameter = "Prosody-" prosody-param-name ":" prosody-param-value CRLF
韻律パラメータ= "Prosody-" 韻律-PARAM名 "：" 韻律-PARAM値CRLF
prosody-param-name = 1*ALPHA
韻律-PARAM-名= 1 * ALPHA
prosody-param-value = 1*alphanum
韻律-PARAM-値= 1 *のalphanum
vendor-specific = "Vendor-Specific-Parameters" ":" vendor-specific-av-pair *[";" vendor-specific-av-pair] CRLF
ベンダー固有= "ベンダー固有パラメータ" "：" ベンダー固有-AV対* [ ";"ベンダー固有-AVペア] CRLF
vendor-specific-av-pair = vendor-av-pair-name "=" vendor-av-pair-value
ベンダー特定のペア=ベンダーAVペア名「=」ベンダーによる対値
vendor-av-pair-name = 1*ALPHA
ベンダーのAVペア名= 1 * ALPHA
vendor-av-pair-value = 1*alphanum
ベンダーのAVペア値= 1 * alphanum
speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF
音声マーカー=「スピーチマーカー」「：」1 * ALPHA CRLF
speech-language = "Speech-Language" ":" 1*ALPHA CRLF
音声言語=「音声言語」「：」1 * ALPHA CRLF
fetch-hint = "Fetch-Hint" ":" 1*ALPHA CRLF
フェッチヒント=「フェッチヒント」を「：」1 * ALPHA CRLF
audio-fetch-hint = "Audio-Fetch-Hint" ":" 1*ALPHA CRLF
オーディオ・フェッチヒント=「オーディオ・フェッチヒント」「：」1 * ALPHA CRLF
fetch-timeout = "Fetch-Timeout" ":" 1*DIGIT CRLF
フェッチ・タイムアウト=「「タイムアウトを取得」：」1 * DIGIT CRLF
failed-uri = "Failed-URI" ":" absoluteURI CRLF
失敗した-URI = "失敗-URI" "：" absoluteURIでCRLF
failed-uri-cause = "Failed-URI-Cause" ":" 1*ALPHA CRLF
= "失敗-URI-原因" "-uriの原因に失敗しました：" 1 * ALPHA CRLF
speak-restart = "Speak-Restart" ":" boolean-value CRLF
話す再始動=「スピーク・再起動」を「：」ブール値CRLF
speak-length = "Speak-Length" ":" speech-length-value CRLF confidence-threshold = "Confidence-Threshold" ":" 1*DIGIT CRLF
話す長= "スピーク-Length" を "：" 発話長値CRLFの信頼しきい値= "自信-しきい値" "：" 1 * DIGIT CRLF
sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF
感度レベル=「感度レベル」「：」1 * DIGIT CRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 1*DIGIT CRLF
スピード-VS-精度= "スピード対精度" "：" 1 * DIGIT CRLF
n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
nベストリスト長= "N-ベスト・リスト長" "：" 1つの* DIGITのCRLF無入力タイムアウト= "無入力タイムアウト" "：" 1 * DIGIT CRLF
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
認識タイムアウト=「認識タイムアウト」「：」1 * DIGIT CRLF
waveform-url = "Waveform-URL" ":" absoluteURI CRLF
波形のurl = "波形-URL" "：" absoluteURIでCRLF
recognizer-context-block = "Recognizer-Context-Block" ":" 1*ALPHA CRLF
認識エンジンコンテキスト・ブロック= "認識装置-コンテキストブロック" "：" 1 * ALPHA CRLF
recognizer-start-timers = "Recognizer-Start-Timers" ":" boolean-value CRLF
認識エンジン・スタート・タイマー=「認識器スタート・タイマー」「：」ブール値CRLF
speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*DIGIT CRLF
音声の完全タイムアウト=「スピーチコンプリート・タイムアウト」「：」1 * DIGIT CRLF
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*DIGIT CRLF
音声不完全タイムアウト= "スピーチ-不完全タイムアウト" "：" 1 * DIGIT CRLF
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*DIGIT CRLF
DTMF-桁間タイムアウト= "DTMF-ディジット間のタイムアウト" "：" 1 * DIGIT CRLF
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
DTMF-用語タイムアウト= "DTMF-ターム・タイムアウト" "：" 1 * DIGIT CRLF
dtmf-term-char = "DTMF-Term-Char" ":" CHAR CRLF
DTMF-用語-CHAR = "DTMF-ターム・シャア" "：" CHAR CRLF
save-waveform = "Save-Waveform" ":" boolean-value CRLF
保存波形=「「波形を保存」：」ブール値CRLF
new-audio-channel = "New-Audio-Channel" ":" boolean-value CRLF
新しいオーディオ・チャンネル=「新しいオーディオチャンネル」「：」ブール値CRLF
Appendix B. Acknowledgements
付録B.謝辞
Andre Gillet (Nuance Communications) Andrew Hunt (SpeechWorks) Aaron Kneiss (SpeechWorks) Kristian Finlator (SpeechWorks) Martin Dragomirecky (Cisco Systems, Inc.) Pierre Forgues (Nuance Communications) Suresh Kaliannan (Cisco Systems, Inc.) Corey Stohs (Cisco Systems, Inc.) Dan Burnett (Nuance Communications)
アンドレ・ジレ（ニュアンスコミュニケーションズ）アンドリュー・ハント（SpeechWorks）アーロンKneiss（SpeechWorks）クリスチャンFinlator（SpeechWorks）マーティンDragomirecky（シスコシステムズ社）ピア・フォーギーズ（ニュアンスコミュニケーションズ）スレシュKaliannan（シスコシステムズ社）コーリーStohs（シスコシステムズ社）ダン・バーネット（ニュアンスコミュニケーションズ）
Authors' Addresses
著者のアドレス
Saravanan Shanmugham Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134
Saravanan Shanmughamシスコシステムズ社170 W.タスマン・ドライブサンノゼ、CA 95134
EMail: sarvi@cisco.com
メールアドレス：sarvi@cisco.com
Peter Monaco Nuasis Corporation 303 Bryant St. Mountain View, CA 94041
ピーター・モナコNuasis株式会社303ブライアントセントマウンテンビュー、CA 94041
EMail: peter.monaco@nuasis.com
メールアドレス：peter.monaco@nuasis.com
Brian Eberman Speechworks, Inc. 695 Atlantic Avenue Boston, MA 02111
ブライアンEberman Speechworks、Inc.の695大西洋アベニューボストン、MA 02111
EMail: brian.eberman@speechworks.com
メールアドレス：brian.eberman@speechworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。