[要約] 要約：RFC 4463は、Cisco、Nuance、およびSpeechworksによって開発されたMedia Resource Control Protocol（MRCP）に関する規格です。 目的：このRFCの目的は、音声認識や音声合成などの音声処理リソースを制御するための標準化されたプロトコルを提供することです。
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
Cisco、Nuance、およびSpeechWorksによって開発されたメディアリソース制御プロトコル（MRCP）
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).
Copyright（c）The Internet Society（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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に登録されていないため、標準のIETF MIMEタイプとして認識されていないMIMEタイプ「アプリケーション/MRCP」を使用していることに注意してください。ただし、この空間で継続的な標準化の祖先としてのこの文書の歴史的価値は、この文書の公開を意味のあるものにします。
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。、Nuance Communications、およびSpeechWorks、Inc。が共同で開発したメディアリソースコントロールプロトコル（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は、ネットワークを介して、音声シンセサイザー、認識機、信号発電機、信号検出器、FAXサーバーなどなどのメディアサービスリソースを制御します。このプロトコルは、RTSP（リアルタイムストリーミングプロトコル）やSIP（セッション開始プロトコル）などのストリーミングプロトコルと連携するように設計されており、外部メディアストリーミングデバイスへの制御接続、およびRTP（リアルタイムプロトコル）などのメディア配信メカニズムを確立するのに役立ちます。
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）は、ネットワーク上の処理リソースを制御するためにオーディオ/ビデオストリーム処理を必要とするクライアントデバイスにメカニズムを提供するように設計されています。これらのメディア処理リソースは、音声認識者（別名自動スピーチ認識（ASR）エンジン）、音声シンセサイザー（別名テキスト対スピーチ（TTS）エンジン）、FAX、信号検出器などです。MRCPにより、変化するインタラクティブな音声の実装が可能になります。応答プラットフォーム、たとえば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プロトコルは、セッションを確立および維持するために、リアルタイムストリーミングプロトコル（RTSP）[2]に依存して、サーバーを使用して制御セッションがどのように確立されるかについては対処していません。セッション制御プロトコルは、クライアントからネットワークサーバーへのメディア接続を確立する責任も担当しています。MRCPプロトコルとそのメッセージングは、セッション説明プロトコル（SDP）と同様のMIMEタイプとしてRTSPまたは別のプロトコルを介して運ばれるように設計されています[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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ストリームを介してFAXを送信または受信できるFAXリソースなどのデータを送信および受信するリソースです。
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では、クライアントとサーバー間のMRCPリクエスト/応答を携帯するために、アナウンスメソッド/応答を使用する必要があります。MRCPメッセージは、RTSPのセットアップまたは分解メッセージで伝えてはなりません。
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サーバーからの非同期イベントは、サーバー開始のアナウンスメソッド/応答通信にパッケージ化されます。サーバーからクライアントに非同期イベントを送信する将来の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セッションは、RTSPセットアップメッセージがクライアントからサーバーに送信され、セッションIDを指定せずにサーバーURLまたはそのリソースURLのいずれかにアドレス指定されるときに作成されます。サーバーはセッションコンテキストを確立し、セッションIDでクライアントに応答します。このシーケンスは、クライアントとサーバー間のRTP輸送パラメーターも設定し、サーバーはメディアストリームを受信または送信する準備ができています。クライアントが既存のセッションに追加のリソースを添付したい場合、クライアントは後続のセットアップメッセージにそのセッションの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からRTSPメソッドをプレイ、レコード、または一時停止する場合、RTSP 405 "メソッドが許可されていない「応答を許可されていない」と応答する必要があります。これらのリソースの場合、許可されている唯一のRTSPメソッドは、セットアップ、断取り込み、説明、および発表です。
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
SPEAK 543257 MRCP/1.0 Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
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>
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
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
MRCP/1.0 543257 200 IN-PROGRESS
MRCP/1.0 543257 200イン進みます
S->C: ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:6
Session:12345678
Content-Type:application/mrcp
Content-Length:123
SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0
Speak-Complete 543257完全な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.
自動音声認識（ASR）エンジンやテキストから音声（TTS）エンジンなどの複数のメディア処理リソースが単一のセッションに使用される場合、RTP/RTCPポートの単一セットがMRCPクライアントとサーバーの間でネゴシエートされ、共有されます。共通のセッション識別子の下でサーバーに割り当てられた個々のリソースインスタンスは、その単一の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）識別子値を使用して区別される複数のメディアストリームをサーバーに向けて送信できます。同様に、サーバーは、複数の同期ソース（SSRC）識別子値を使用して、複数の伝送リソースURLに由来するメディアストリームを区別できます。一方、個々のリソースは、クライアントに1つのストリームだけを送信するために協力する場合があります。これは、メディアサーバーの実装次第です。
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全体は、タイプアプリケーション/MRCPのMIMEエンティティとして、セッションレベルメッセージの本文でエンコードされています。個々のMRCPメッセージには、リクエスト/応答がどのリソース/fromのリソースがあるかに関するアドレス指定情報がありません。代わりに、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メッセージセットは、クライアントからサーバーへのリクエスト、サーバーからクライアントへの応答、サーバーからクライアントへの非同期イベントで構成されています。これらのメッセージはすべて、起動線、1つ以上のヘッダーフィールド（「ヘッダー」とも呼ばれます）、空の行（つまり、CRLFに先行するものがないライン）、ヘッダーフィールドの終了を示す行、およびオプションのメッセージで構成されています。体。
generic-message = start-line message-header CRLF [ message-body ]
generic-message = start-line message-header crlf [message-body]
message-body = *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
request-line = method-name sp request-id sp mrcp-version 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
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フィールドは、クライアントがサーバーに行っている特定のリクエストを識別します。各リソースは、発行できるリクエストまたはメソッドの特定のリストをサポートし、後のセクションで説明します。
method-name = synthesizer-method / recognizer-method
method-name = synthesizer-method / rucledizer-method
The mrcp-version field is the MRCP protocol version that is being used by the client.
MRCP-versionフィールドは、クライアントが使用しているMRCPプロトコルバージョンです。
mrcp-version = "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
Response-line = MRCP-version sp request-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バージョンフィールドは、リクエストラインで使用されているフィールドと類似しており、サーバーで実行されている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.
要求国家フィールドは、リクエストによって開始されたジョブが保留中、進行中、または完全であるかどうかを示します。完全なステータスは、リクエストが完了まで処理され、そのリクエストIDを使用してそのリソースからクライアントにこれ以上イベントがないことを意味します。保留中のステータスは、ジョブがキューに配置され、ファーストインで処理されることを意味します。進行中のステータスは、リクエストが処理されており、まだ完了していないことを意味します。保留中または進行中のステータスは、そのリクエストIDでさらにイベントメッセージが配信されることを示します。
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
request-state = "complete" / "in-progress" / "pending"
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.
いくつかのオプションのパラメーターを使用した200の成功201成功は無視されました。
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
401許可されていない402この状態で無効402メソッド403サポートされていないパラメーター404パラメーター405の違法値は見つかりません（例：リソースURIが初期化されていない、または存在しない）認識者。詳細な原因コードは、リソース固有のヘッダーフィールドを介して利用できる場合があります。）408認識されていないまたはサポートされていないメッセージエンティティ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.
サーバーリソースは、状態の変更または特定のイベントの発生をクライアントに伝える必要がある場合があります。これらのメッセージは、リクエストがすぐに完了せず、応答が保留中または進行中のステータスを返す場合に使用されます。リクエストの中間結果とイベントは、サーバーからのイベントメッセージを介してクライアントに示されます。イベントには、進行中のリクエストのリクエストIDがあり、これらのイベントとステータス値を生成しています。リクエストが完了し、これが最後のイベントである場合、ステータス値は完了します。そうでなければ、進行中です。
event-line = event-name SP request-id SP request-state SP mrcp-version CRLF
event-line = event-name sp request-id sp request-state sp mrcp-version 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
event-name = synthesizer-event / raudeizer-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.
General-Header（セクション5.4）およびリソース固有のヘッダー（セクション7.4および8.4）を含むMRCPヘッダーフィールドは、RFC 2822のセクション2.1 [7]のセクション2.1に記載されている一般的な形式と同じ一般的な形式に従います。各ヘッダーフィールドは、名前とコロン（ "："）とフィールド値が続く名前で構成されています。フィールド名はケースに依存しません。フィールド値の前には、単一のspが推奨されますが、任意の量の線形ホワイトスペース（LWS）が先行する場合があります。ヘッダーフィールドは、少なくとも1つのSPまたはHTを使用して各追加ラインに先行することにより、複数のラインに拡張できます。
message-header = 1*(generic-header / resource-header)
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つの「Field-Name：Field-Value」ペアに結合し、その後の各フィールド値を最初のフィールド値に追加し、それぞれをコンマで区切ることにより、可能でなければなりません。したがって、同じフィールド名を持つヘッダーフィールドが受信される順序は、合計フィールド値の解釈にとって重要であるため、メッセージが転送されたときにプロキシはこれらのフィールド値の順序を変更してはなりません。
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
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のリストを示します。これは、保留中または進行中の複数のリクエストがあり、このリクエストがこれらの1つ以上に具体的に適用することを望む場合に役立ちます。
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つ以上の要求がある可能性があります。1つ以上の保留中の要求または進行中の要求に影響を与えるメソッドがクライアントからサーバーに送信される場合、応答には、このヘッダーフィールドで影響を受けたリクエストIDのリストを含める必要があります。
The active-request-id-list is only used in requests and responses, not in events.
Active-Request-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.
たとえば、Active-Request-IDリストのないストップリクエストがシンセサイザーリソース（ワイルドカードストップ）に送信された場合、保留中または進行中の状態で1つ以上のスピーチリクエストがある場合、すべてのスピーチリクエストをキャンセルする必要があります。進行中の1つを含む。さらに、STOPリクエストへの応答には、Active-Request-IDリストで終了したすべてのSPEKリクエストのリクエストIDが含まれます。この場合、これらの終了リクエストのために、話す完全または認識が完了したイベントは送信されません。
active-request-id-list = "Active-Request-Id-List" ":" request-id
*("," request-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.
サーバーリソースがバージに入れられるイベントを生成すると、一意のタグを生成し、クライアントにイベントでヘッダーフィールドとして送信します。その後、クライアントはサーバーリソースのプロキシとして機能し、サーバーリソースから受け取ったプロキシ-Sync-IDを使用して、シンセイザーサーバーリソースに分泌されたメソッド（セクション7.10）を送信します。認識者とシンセサイザーのリソースが同じセッションの一部である場合、彼らはより迅速な相互作用と応答を実現するために協力することを選択できます。ここでは、Proxy-Sync-IDは、クライアントがプロキシで紹介するイベントを受信するリソースが、このイベントがリソースの直接的な相互作用を通じて処理されたかどうかを判断するのに役立ちます。
proxy-sync-id = "Proxy-Sync-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]を参照してください。これは、この要求に関連する応答またはイベントで返されるエンティティの許容可能な文字セットを指定します。これは、自然言語セマンティクスマークアップ言語（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
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-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
content-coding = token
token = 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
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 URIにアクセスしてキャッシュするときに、HTTP 1.1（RFC2616）のキャッシュ正しさルールを遵守する必要があります。特に、キャッシュされた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
delta-seconds = 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であることを示します。最大段階のディレクティブも含まれていない限り、クライアントは古い応答を使用してメディアサーバーを受け入れる意思がありません。
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
マックスステール
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-Staleに値が割り当てられている場合、クライアントは、指定された秒数以下の有効期限を超えた応答を使用してメディアサーバーを受け入れることをいとわない。マックスステールに値が割り当てられていない場合、クライアントはあらゆる年齢の古い応答を使用してメディアサーバーを受け入れることをいとわない。
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.
メディアサーバーのキャッシュは、検証なしで古い応答/データを使用するように要求される場合がありますが、これがキャッシュの検証（例えば、「必須」キャッシュ制御指令）に関する「マスト」レベルの要件と競合しない場合のみです。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キャッシュコントロール指令とメディアサーバーのキャッシュエントリの両方に「Max-Age」ディレクティブが含まれている場合、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
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記述メカニズムを使用して見つけることができます。クライアントがMedia Resource URIのRTSPを発行する場合、メディアサーバーの応答には、メディアサーバーリソースの機能を説明するMedia Server Responseが本体にSDP説明を含める必要があります。SDPの説明には、コードックおよびサポートする他のメディア関連機能を説明するメディアヘッダー（M-Line）を少なくとも含める必要があります。別の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.
RTSPメッセージ本文でのSDPメッセージの使用法とそのアプリケーションは、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ポートのセットを割り当てる必要があり、最初のリソースのセットアップメッセージにセッションIDを送信してはなりません。サーバーはセッションIDを作成し、サーバーRTP/RTCPポートのセットを割り当て、セットアップメッセージに応答します。
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.
クライアントが同じセッションで同じサーバーを使用してより多くのリソースを開きたい場合、新しいリソースのセットアップでセッションID（以前のセットアップ応答に入ったこと）を送信します。既存のSession-IDを使用したセットアップメッセージは、この新しいリソースが既存のセッションの同じ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ヘッダーフィールドのない個別のセットアップリクエストを送信します。各サーバーは独自のセッション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セットアップ応答には、そのセッションで受信して送信することが期待されるメディアストリームの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.
クライアントからのセットアップメソッドのSDP説明には、Codec、名前付きシグナリングイベント（NSE）ペイロードタイプなどの必要なメディアパラメーターを説明する必要があります。から選択するオプションが複数あるメディアサーバー。
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.
セットアップ応答のSDP説明は、メディアサーバーがストリームに使用するメディアパラメーターを反映する必要があります。設定方法の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
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
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
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
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.
RTSPセットアップメソッドでSDPの説明が提供されていない場合、メディアサーバーはストリームのパラメーターを決定しますが、セットアップ応答で選択したものを指定する必要があります。SDPの発表は、セッションを指定しないセットアップメッセージへの応答でのみ返されます。つまり、サーバーは、既に認識者で確立されたセッションのシンセサイザーセットアップのSDPアナウンスを返しません。
C->S:
c-> s：
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0
CSeq:1
Transport:RTP/AVP;unicast;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
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
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リクエストを相関させる必要があるため、状態を維持しています。以下に示す状態の移行は、シンセサイザーの状態を説明し、キューの頭での要求を反映しています。保留中の状態での話すリクエストは、停止リクエストによって削除または停止することができ、リソースの状態に影響しません。
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"
The synthesizer may generate the following events.
シンセサイザーは、次のイベントを生成する場合があります。
synthesizer-event = "SPEECH-MARKER" / "SPEAK-COMPLETE"
Synthesizer-Event = "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
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
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".
このパラメーターは、制御方法で指定され、ジャンプサイズを制御して、アクティブな話すリクエストで前方に移動または巻き戻します。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"
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.
このパラメーターは、バージオンサポートを可能にするためのSPEKメソッドの一部として送信される場合があります。有効にすると、SPEKメソッドは、信号検出器リソースによって検出されたDTMF入力によって、または音声認識者リソースによって検知または認識された音声の開始によって中断されます。
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF
boolean-value = "true" / "false"
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".
SynterSesizerと同じサーバーであるRecoldizerまたはSignal Detectorリソースがオンになっている場合、サーバーは一般的なRTSP Session-IDによる相互作用を認識し、互いに協力してバージオンサポートを提供するのに十分なインテリジェントでなければなりません。クライアントは、シンセサイザーリソースまたは信号検出器リソースからバージイン可能なイベントを受け取ったときに、シンセサイザーリソースにバージに入れられたメソッドを送信する必要があります。これらのリソースは、ローカルまたは分散される場合があります。このフィールドが指定されていない場合、値はデフォルトで「true」になります。
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.
このパラメーターは、セットパラム/get-paramsの一部であるか、クライアントからサーバーへのスピーチリクエストの一部であり、性別、アクセントなどの音声パラメーターのセットであるURIによってスピーカーのプロファイルを指定します。
speaker-profile = "Speaker-Profile" ":" 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リクエストの完了の背後にある理由を示しています。
completion-cause = "Completion-Cause" ":" 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通常の話す正常に完了します。001 Barge-in Speakリクエストは、バージインのために終了しました。002スピーチマークアップテキストを解析できなかったために終了した002解析スピーチリクエスト。003 URI-Failure Speakリクエストが終了しました。これは、URIの1つへのアクセスが失敗したためです。004エラースピーチリクエストは、シンセサイザーエラーにより早期に終了しました。005言語がサポートされていない言語はサポートされていません。
This set of parameters defines the voice of the speaker.
このパラメーターのセットは、スピーカーの声を定義します。
voice-parameter = "Voice-" voice-param-name ":" voice-param-value CRLF
Voice-Parameter = "Voice-" Voice-Param-Name "：" Voice-Param-Value 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.
Voice-Param-Nameは、W3Cの音声合成マークアップ言語仕様で指定された音声要素の下にある属性名のいずれかです[9]。Voice-Param-Valueは、上記のセクションで指定された対応するVoice Element属性の値の選択のいずれかです。
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).
これらのヘッダーフィールドは、セッション全体のデフォルト値を定義/取得するためにSet-Params/Get-Paramsリクエストで送信されるか、Speakリクエストで送信して、そのSpeakリクエストのデフォルト値を定義することができます。さらに、これらの属性は、音声合成マークアップ言語（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.
これらの音声パラメーターヘッダーフィールドは、進行中のスピーチリクエストに影響を与え、その場での動作を変更するために、制御方法で送信することもできます。シンセサイザーリソースがこの操作をサポートしていない場合、サポートされていないステータスでクライアントに応答する必要があります。
This set of parameters defines the prosody of the speech.
この一連のパラメーターは、スピーチの韻律を定義します。
prosody-parameter = "Prosody-" prosody-param-name ":" prosody-param-value CRLF
prody-parameter = "prody-" prosody-param-name "：" prosody-param-value 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.
Prosody-Param-Nameは、W3Cの音声合成マークアップ言語仕様で指定された韻律要素の下にある属性名のいずれかのいずれかです[9]。Prosody-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.
これらのヘッダーフィールドは、セッション全体のデフォルト値を定義/取得するためにSet-Params/Get-Paramsリクエストで送信されるか、Speakリクエストで送信して、そのSpeakリクエストのデフォルト値を定義することができます。さらに、これらの属性は、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またはSPEKリクエストのProsodyパラメーターヘッダーフィールドは、スピーチデータがタイプテキスト/プレーンであり、スピーチマークアップ形式を使用しない場合にのみ適用されます。
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.
これらの韻律パラメーターヘッダーフィールドは、進行中のスピーチリクエストに影響を与え、その場での動作を変更するために、制御方法で送信することもできます。シンセサイザーリソースがこの操作をサポートしていない場合、サポートされていないステータスでクライアントに応答する必要があります。
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
Vendor-specific = "ベンダー固有のパラメーター" "："ベンダー固有のav-pair *[";"ベンダー固有のav-pair] crlf
vendor-specific-av-pair = vendor-av-pair-name "=" vendor-av-pair-value
ベンダー特有のav-pair = vendor-av-pair-name "=" vendor-av-pair-value
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-Pair-Nameは、任意のベンダー固有のフィールド名であり、XMLベンダー固有の属性命名条約に準拠しています。ベンダー-AV-PAIR-VALUEは、属性を設定する値であり、引用する必要があります。
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" ":" 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.
このヘッダーフィールドは、音声データで指定されていない場合、音声データのデフォルト言語を指定します。このヘッダーフィールドの値は、その値についてRFC 3066 [16]に従う必要があります。これは、Speak、Set-Params、Get-Paramsリクエストで発生する場合があります。
speech-language = "Speech-Language" ":" 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、またはGet-Paramsリクエストで発生する場合があります。
fetch-hint = "Fetch-Hint" ":" 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、またはGet-Paramsリクエストで発生する場合があります。
audio-fetch-hint = "Audio-Fetch-Hint" ":" 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、またはGet-Paramsで発生する場合があります。
fetch-timeout = "Fetch-Timeout" ":" 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
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
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.
コントロールジャンプ後方リクエストが現在話しているシンセサイザーリソースに発行され、スピーチの開始を超えてジャンプすると、現在のSPEKリクエストはスピーチデータの開始から再起動し、制御要求への応答にはこのヘッダーが含まれます。再起動。このヘッダーは、制御応答で発生する場合があります。
speak-restart = "Speak-Restart" ":" boolean-value 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リクエストの現在の発話点と比較して、発言の長さを制御するための制御方法で指定される場合があります。この分野では、「 - 」値は違法です。タグユニットを備えたフィールドが指定されている場合、メディアはタグに到達するか、スピーチリクエストが完了するまで、どちらか早い方で話す必要があります。これは、スピーチデータで話す長さを示すために、Speedリクエストで指定され、Speak Requestが開始されるスピーチのポイントに関連しています。サポートされている異なる音声長さユニットは、シンセサイザーの実装に依存します。ユニットまたは操作をサポートしていない場合、リソースは404「パラメーターの違法またはサポートされていない値」のステータスコードで応答する必要があります。
speak-length = "Speak-Length" ":" speech-length-value
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.
すべてのメディアサーバーは、プレーンテキストの音声データとW3Cの音声合成マークアップ言語[9]を少なくともサポートする必要があります。
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タイプのテキスト/URIリストを使用して、話す必要があるものをリストする1つ以上のURIを指定します。URISのスピーチのリストが指定されている場合、各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またはテキスト/プレーン用のMIMEブロックが埋め込まれます。音声データで使用される文字セットとエンコードは、標準のMIMEタイプの定義に従って指定できます。マルチパートMIMEブロックには、.WAVまたはSUNオーディオ形式の実際のオーディオデータを含めることができます。これは、クライアントが記録した可能性のあるオーディオクリップを持ち、メモリまたはローカルデバイスに保存し、現在Speakリクエストの一部として再生する必要がある場合に使用されます。オーディオマイムパートは、マルチパートMIMEブロックの一部としてクライアントから送信できます。このオーディオは、マルチパート/ミックスMIMEタイプの仕様に従って、マルチパートMIMEブロックの別の部分となるスピーチマークアップデータで参照されます。
Example 1: Content-Type:text/uri-list Content-Length:176
例1：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
Example 2:
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>
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
Example 3:
Content-Type:multipart/mixed; boundary="--break"
--break Content-Type:text/uri-list Content-Length:176
- ブレイクコンテンツタイプ：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
- ブレイクコンテンツタイプ：アプリケーション/合成SSMLコンテンツレングス：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>
--break
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 Voice-Gender：女性の音声カテゴリ：アダルト音声variant：3
S->C:MRCP/1.0 543256 200 COMPLETE
S-> C：MRCP/1.0 543256 200完全
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メソッドは、音声特性や韻律などの現在のシンセサイザーコンテキストパラメーターについてシンセサイザーリソースに要求します。クライアントは、セットをリストしてサーバーから読みたいパラメーターのリストを送信する必要があります。空のパラメーターヘッダーフィールドの。特定のリストが指定されていない場合、サーバーはベンダー固有のパラメーターとその現在の値を含むすべての設定可能なパラメーターを返す必要があります。ベンダーに応じて、設定可能なパラメーターの数が大きくなる可能性があるため、ワイルドカードの使用は非常に集中的です。したがって、クライアントはWildCard 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 Voice-Gender：Voice-Category：Voice-Variant：ベンダー固有のパラメーター：com.mycorp.param1;com.mycorp.param2
S->C:MRCP/1.0 543256 200 COMPLETE
Voice-gender:female
Voice-category:adult
Voice-variant: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つのレベルにはスコープがあります。最も高い優先順位は、スピーチマークアップテキスト内で指定されたものであり、その後、Speakリクエストのヘッダーフィールドで指定されたものが続くため、Set-Paramsを使用して設定できるセッションデフォルト値のみを適用します。前進するセッション全体をリクエストし、申請してください。
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リクエストが積極的に処理されている場合、リソースは成功ステータスコードと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.
リソースがスピーキング状態または一時停止状態にある場合（つまり、以前のスピーキングリクエストの処理中にあります）、ステータスは成功と保留中の要求状態を返します。これは、このSPEKリクエストがキューにあることを意味し、現在アクティブな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
<?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 543257 200 IN-PROGRESS
S-> c：MRCP/1.0 543257 200入力
S->C:SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0 Completion-Cause:000 normal
S-> c：Speak-complete 543257完全なmrcp/1.0 Rextion-Caus：000 Normal
The STOP method from the client to the server tells the resource to stop speaking if it is speaking something.
クライアントからサーバーへの停止方法は、リソースに何かを話している場合に話すのをやめるように指示します。
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.
STOPリクエストは、アクティブなRequest-ID-Listヘッダーフィールドで送信して、キューにある可能性のあるゼロ以下の具体的なスピーチリクエストを停止し、200の応答コード（成功）を返すことができます。STOPリクエストでActive-Request-ID-Listヘッダーフィールドが送信されない場合、すべての未解決の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リクエストが1つ以上の保留中または進行中のスピーチリクエストを正常に終了した場合、応答メッセージ本文には、終了したSpeak Request-IDをリストするアクティブなRequest-ID-Listヘッダーフィールドが含まれています。それ以外の場合、応答にアクティブなRequest-ID-Listヘッダーフィールドはありません。これらの終了リクエストのために、話す完全なイベントは送信されません。
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.
進行中で発言が停止した話のリクエストが停止した場合、次の保留中の話のリクエストは、もしあれば、進行中になり、話す状態に移動します。
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.
進行中で一時停止状態での話す要求が停止された場合、次の保留中の話の要求は、もしあれば、進行中になり、一時停止された状態に移動します。
Example:
C->S:SPEAK 543258 MRCP/1.0
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>
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S-> c：MRCP/1.0 543258 200 in-progress
C->S:STOP 543259 200 MRCP/1.0
C-> s：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完全なアクティブリケスト-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.
バージインクレイドメソッドは、クライアントがスピーチリソースに検出したバージイン可能なイベントを伝えるメカニズムです。
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. 認識者リソースとシンセサイザーリソースは、さまざまなサーバーにあります。その場合、クライアントはプロキシとして行動し、認識リソースからイベントを受信し、その後、シンセサイザーに手すりのメソッドを送信する必要があります。このような場合、バージインオキカルメソッドには、元のイベントを生成するリソースから受け取ったプロキシ-Sync-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.
Barge-in-Barge-inが有効になっていると、Speak Requestがアクティブであり、Barge-in-ccurredイベントが受信された場合、シンセサイザーはオーディオのストリーミングを停止する必要があります。また、バージインを有効にしているかどうかに関係なく、現在のアクティブなものの背後にキューのある音声リクエストを終了する必要があります。バージイン可能なプロンプトが再生され、終了した場合、応答には、アクティブレクエストIDリストで終了したすべてのSPEKリクエストのリクエストIDを含める必要があります。これらのリクエストのために生成される話す完全なイベントはありません。
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に基づいて直接対話させることにより、より迅速な殺害対象の応答のために最適化できます。これらの場合、クライアントは引き続き開催された方法を通じて認識イベントをプロキシする必要がありますが、シンセサイザーリソースはすでに停止しており、バージイン完成原因コードを備えたSpeak Completeイベントを送信している可能性があります。脱出方法の結果として終了したスピーチリクエストがなかった場合、応答はまだ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
<?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：MRCP/1.0 543258 200 in-progress
C->S:BARGE-IN-OCCURRED 543259 200 MRCP/1.0 Proxy-Sync-Id:987654321
C-> s：バージ・イン・オーキュール543259 200 MRCP/1.0 Proxy-Sync-ID：987654321
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP/1.0 543259 200完全なアクティブリケスト-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.
クライアントからサーバーへの一時停止方法は、何かを話している場合、スピーチを一時停止するリソースに指示します。SPEKがアクティブでない場合、セッションで一時停止方法が発行された場合、サーバーは402または「この状態では有効ではない方法」のステータスで応答する必要があります。話がアクティブで一時停止したときにセッションで一時停止方法が発行される場合、サーバーは200または「成功」のステータスで応答する必要があります。Speak Requestがアクティブな場合、サーバーは、一時停止されたSpeakリクエストのリクエストIDを使用してアクティブなRequest-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
<?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：MRCP/1.0 543258 200 in-progress
C->S:PAUSE 543259 MRCP/1.0
C-> s：543259 MRCP/1.0の一時停止
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP/1.0 543259 200完全なアクティブリケスト-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
クライアントからサーバーへの履歴書方法は、一時停止したシンセサイザーリソースに話し続けるように指示します。履歴書メソッドが、話がアクティブでない場合にセッションで発行される場合、サーバーは402または「この状態では有効ではない方法」のステータスで応答する必要があります。履歴書メソッドが、話すことがアクティブで話している（つまり、一時停止しない）ときにセッションで発行される場合、サーバーは200または「成功」のステータスで応答する必要があります。Speak Requestがアクティブな場合、サーバーは再開されたSPEKリクエストのリクエストIDを使用してActive-Request-ID-Listヘッダーを返す必要があります
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
<?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：MRCP/1.0 543258 200 in-progress
C->S:PAUSE 543259 MRCP/1.0
C-> s：543259 MRCP/1.0の一時停止
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP/1.0 543259 200完全なアクティブリケスト-IDリスト：543258
C->S:RESUME 543260 MRCP/1.0
C-> s：履歴書543260 MRCP/1.0
S->C:MRCP/1.0 543260 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP/1.0 543260 200完全なアクティブリケスト-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.
クライアントからサーバーへの制御方法は、その場で話していることを変更するために話しているシンセサイザーに伝えます。この方法は、シンセサイザーが話されていることを前または後方にジャンプさせるために使用され、スピーカーレートやスピーカーのパラメーターを変更します。シンセサイザーリソースの実装と能力に応じて、この操作またはそのパラメーターの1つ以上が可能になる場合があります。
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.
前方にジャンプするコントロールが発行され、操作がActive Speakメソッドのテキストの終わりを超えた場合、リクエストは成功します。Speak Completeイベントは、制御方法への応答に従います。キューにもっと話すリクエストがある場合、シンセサイザーリソースは引き続き次の話方法を処理します。後方にジャンプするコントロールが発行され、操作がアクティブなスピーチリクエストの音声データの先頭にジャンプすると、コントロール要求への応答にはスピーチリステルートヘッダーが含まれます。
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.
これらの2つの動作は、クライアントがスピーチマークアップテキストを複数のSpeakリクエストに分割したい場合、複数の音声リクエストを巻き戻すか、早送りするために使用できます。
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.
制御方法が受信されたときにSPEKリクエストがアクティブであった場合、サーバーはアクティブなSPEKリクエストのリクエストIDを使用してActive-Request-ID-Listヘッダーを返す必要があります。
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
<?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：MRCP/1.0 543258 200 in-progress
C->S:CONTROL 543259 MRCP/1.0 Prosody-rate:fast
C-> s：コントロール543259 MRCP/1.0韻律率：高速
S->C:MRCP/1.0 543259 200 COMPLETE Active-Request-Id-List:543258
S-> C：MRCP/1.0 543259 200完全なアクティブリケスト-IDリスト：543258
C->S:CONTROL 543260 MRCP/1.0
C-> s：コントロール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完全なアクティブリケスト-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.
これは、シンセサイザーリソースからクライアントへのイベントメッセージであり、SPEKリクエストが完了したことを示しています。Request-IDヘッダーフィールドは、完了したばかりのスピーチを開始したSPEKリクエストのリクエストIDと一致します。リクエスト状態のフィールドは、これがそのリクエストIDの最後のイベントであり、そのリクエストIDのリクエストが完了したことを示す完全である必要があります。完了原因ヘッダーフィールドは、正常に完了した、またはエラーや駐車中の発言などのために、ステータスとリクエスト完了の理由に関連する原因コードを指定します。
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
<?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 543260 200 IN-PROGRESS
S-> c：MRCP/1.0 543260 200入力
S->C:SPEAK-COMPLETE 543260 COMPLETE MRCP/1.0
S-> C：Speak-Complete 543260 CompleteMRCP/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 Request-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
<?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：MRCP/1.0 543261 200入力
S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0 Speech-Marker:here
S-> C：Speech-Marker 543261 In-ProgressMRCP/1.0 Speech-Marker：こちら
S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0 Speech-Marker:ANSWER
S-> C：Speech-Marker 543261 In-ProgressMRCP/1.0 Speech-Marker：回答
S->C:SPEAK-COMPLETE 543261 COMPLETE MRCP/1.0 Completion-Cause:000 normal
S-> C：Speak-Complete 543261 Complete MRCP/1.0 Reftilecause：000 Normal
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.
Speech Recoldizerリソースは、着信音声ストリームを受け取り、クライアントにテキスト形式で話されたことの解釈を提供することができます。
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
The recognizer may generate the following events.
認識者は、次のイベントを生成する場合があります。
recognizer-event = START-OF-SPEECH / RECOGNITION-COMPLETE
Recoldizer-Event =スピーチの開始 /認識が完全
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
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
信頼性授与義の必須セットパラム、Get-Result Sensit-Revelオプションのセットパラム、Get-Paramsを認識し、Speed-VS Accuracyオプションのセットパラム、Get-Paramsを認識し、N-Best-List-Length Optional Set-認識パラメーション、get-params、認識、get-result no-input-timeout tangertoration set-params、get-params、認識
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
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.
認識リソースが話し言葉の一部を文法の一部と認識または一致させると、自信レベルをその結論に関連付けます。信頼性授与パラメーターは、認識者リソースに、どの信頼レベルが成功した一致と見なされるべきかを伝えます。これは0-100の整数であり、認識に対する認識者の自信を示しています。認識者が、すべての認識結果に対する信頼性が信頼のしきい値よりも少ないと判断した場合、認識結果としてマッチを返す必要があります。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。このフィールドのデフォルト値は、プラットフォーム固有です。
confidence-threshold = "Confidence-Threshold" ":" 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.
バックグラウンドノイズをフィルタリングし、音声と間違えないために、認識者は音の感度の可変レベルをサポートする場合があります。感度レベルのパラメーターにより、クライアントはこの値を認識者に設定できます。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。このフィールドの値が高いということは、より高い感度を意味します。このフィールドのデフォルト値は、プラットフォーム固有です。
sensitivity-level = "Sensitivity-Level" ":" 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の使用率が高いことを意味する場合があります。つまり、メディアサーバーごとの呼び出しが少なくなり、その逆も同様です。リソース上のこのパラメーターは、Speed-VS Accuracyヘッダーによって調整できます。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。このフィールドの値が高いということは、より高い速度を意味します。このフィールドのデフォルト値は、プラットフォーム固有です。
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 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より大きい値は、認識者が要求された数の代替案を送信することを保証するものではありません。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。このフィールドの最小値は1です。このフィールドのデフォルト値は1です。
n-best-list-length = "N-Best-List-Length" ":" 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, 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.
認識が開始され、一定の期間スピーチが検出されない場合、認識者はクライアントに認識を完了するイベントを送信し、認識操作を終了できます。入力時間のないヘッダーフィールドは、このタイムアウト値を設定できます。値はミリ秒単位です。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。このフィールドの値は、0からmaxtimeoutの範囲で、Maxtimeoutはプラットフォーム固有です。このフィールドのデフォルト値は、プラットフォーム固有です。
no-input-timeout = "No-Input-Timeout" ":" 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.
認識が開始され、一定の期間に一致しない場合、認識者はクライアントに認識完了イベントを送信し、認識操作を終了できます。認識時間パラメーターフィールドは、このタイムアウト値を設定します。値はミリ秒単位です。このフィールドの値は、0からmaxtimeoutの範囲で、Maxtimeoutはプラットフォーム固有です。デフォルト値は10秒です。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。
recognition-timeout = "Recognition-Timeout" ":" 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.
Save-WaveformヘッダーフィールドがTrueに設定されている場合、認識者は認識の受信オーディオストリームをファイルに記録し、クライアントがアクセスできるURIを提供する必要があります。Save-WaveformヘッダーフィールドがTrueに設定されている場合、このヘッダーは認識完了イベントに存在する必要があります。サーバーの記録を防ぐエラー条件がある場合、ヘッダーのURL値はnullでなければなりません。それ以外の場合、サーバーによって生成されたURLは、サーバーとそのすべての認識セッション全体でグローバルに一意である必要があります。URLは、セッションが取り壊されるまで利用できるようにする必要があります。
waveform-url = "Waveform-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.
このヘッダーフィールドは、認定リソースからクライアントへの認識完了イベントの一部でなければなりません。これは、認識メソッドの完了の背後にある理由を示しています。このヘッダーフィールドは、障害ステータスと完全な状態で戻ってくる場合、定義文法で送信し、応答を認識する必要があります。
Cause-Code Cause-Name Description
原因コード原因という説明
000 success RECOGNIZE completed with a match or DEFINE-GRAMMAR succeeded in downloading and compiling the grammar
000の成功は、マッチで完了したことを認識するか、文法のダウンロードとコンパイルに成功したグラマーを定義します
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.
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メソッドに価値のないこのヘッダーフィールドが含まれている場合、Recoldizerのコンテキストブロックを返すことは認識者に要求されます。このようなメッセージへの応答には、メッセージエンティティとしての認識者コンテキストブロックが含まれる場合があります。サーバーが認識機コンテキストブロックを返す場合、応答はこのヘッダーフィールドを含める必要があり、その値はそのエンティティのコンテンツ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
Recoldizer-context-block = "radeizer-context-block" "：" 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".
このパラメーターは、認識要求の一部として送信される場合があります。偽の値は、認識者に認識を開始するように指示しますが、非入力タイマーをまだ開始しないようにします。クライアントが認識スタートタイマーのリクエストを承認者に送信するまで、認識者はタイマーを起動しないでください。これは、認識機とシンセサイザーエンジンが同じセッションの一部ではないシナリオで役立ちます。ここでは、バージュインプロンプトが再生されている場合、認識要求を同時にアクティブにして、バージオンキルインを検出および実装できるようにします。しかし同時に、プロンプトが終了するまで、認識者が入力なしタイマーを起動することは望ましくありません。デフォルト値は「true」です。
recognizer-start-timers = "Recognizer-Start-Timers" ":" boolean-value CRLF
Recoldizer-Start-Timers = "Recoldizer-Start-Timers" "：" boolean-value 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-Pair-Nameは、任意のベンダー固有のフィールド名であり、XMLベンダー固有の属性命名条約に準拠しています。ベンダー-AV-PAIR-VALUEは、属性を設定する値であり、引用する必要があります。
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メソッドで送信して、セミコロンによって分離されます。このヘッダーフィールドは、セットパラムまたはget-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.
このヘッダーフィールドは、スピーチ認識が結果を確定する前に、ユーザースピーチの後に必要な沈黙の長さを指定します（それを受け入れるか、ノマッチイベントを投げる）。Speech-Complete-Timeout値は、現在、認識者がアクティブな文法の完全なマッチを持っている場合に使用され、一致を宣言する前に、より多くの入力を待つ時間を指定します。対照的に、スピーチがアクティブな文法との不完全な一致である場合、不完全なタイムアウトが使用されます。値はミリ秒単位です。
speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*DIGIT CRLF
Speech-CompleteTimeOut = "Speech-CompleteTimeout" "：" 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.
スピーチが複雑になっている長い時間の値は、結果の完了を遅らせるため、コンピューターの応答が遅くなります。短いスピーチが完全に時間をかけると、発話が不適切に分割される可能性があります。合理的な完全なタイムアウト値は、通常、0.3秒から1.0秒の範囲です。このフィールドの値は、0からmaxtimeoutの範囲で、Maxtimeoutはプラットフォーム固有です。このフィールドのデフォルト値は、プラットフォーム固有です。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。
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イベントで）。値はミリ秒単位です。このフィールドの値は、0からmaxtimeoutの範囲で、Maxtimeoutはプラットフォーム固有です。このフィールドのデフォルト値は、プラットフォーム固有です。
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*DIGIT CRLF
Speech-Incomplete-Timeout = "Speech-IntextreteTimeout" "：" 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.
音声が不完全な時期には、通常、スピーチが完全に時間をかけているよりも長く、ユーザーがミッドオーダーランスを一時停止できるようにします（たとえば、呼吸する）。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。
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入力を認識するときに使用する桁の間のタイムアウト値を指定します。値はミリ秒単位です。このフィールドの値は、0からmaxtimeoutの範囲で、Maxtimeoutはプラットフォーム固有です。デフォルト値は5秒です。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*DIGIT CRLF
dtmf-interdigit-timeout = "dtmf-interdigit-timeout" "：" 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-term-timeout = "DTMF-Term-Timeout" ":" 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です。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。
dtmf-term-char = "DTMF-Term-Char" ":" 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アクセスプロパティを制御します。これにより、メディアサーバーがネットワークから必要とするリソースのフェッチを完了するための認識タイムアウトが定義されます。値はミリ秒単位です。このフィールドの値は、0からmaxtimeoutの範囲で、Maxtimeoutはプラットフォーム固有です。このフィールドのデフォルト値は、プラットフォーム固有です。このヘッダーフィールドは、認識、セットパラム、またはget-paramsで発生する場合があります。
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.
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.
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ヘッダーフィールドに戻ったURIの形でクライアントが利用できるようにする必要があります。ストリームの記録にエラーが発生した場合、またはオーディオクリップが使用できない場合、認識者は空の波形-URIヘッダーフィールドを返す必要があります。このフィールドのデフォルト値は「false」です。
save-waveform = "Save-Waveform" ":" boolean-value 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
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.
このヘッダーフィールドは、データ内で指定されていない場合、セッションまたはリクエスト内の認識文法データの言語を指定します。このヘッダーフィールドの値は、その値についてRFC 3066 [16]に従う必要があります。これは、定義、認識、セットパラム、または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.
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のXMLやABNF、またはSunのJavaスピーチ文法形式などの標準的な文法仕様形式の1つで指定されています。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で新しい文法を定義することで上書きすることができます。コンテンツIDに関連付けられている文法は、特別な「セッション：」URIスキームを通じて参照できます。
Example: session: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.
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またはインライン文法ブロックが認識要求のメッセージ本文で指定されている場合、それは聞くべき文法の代替品のアクティブなリストです。リストの順序は、グラマーの優先順位を意味し、リストの最初の文法が最も優先されます。
Example 1:
Content-Type:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
<!-- 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>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- 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>
</grammar>
</grammar>
Example 2: Content-Type:text/uri-list 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
Example 3:
Content-Type:multipart/mixed; boundary="--break"
--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
- ブレイクコンテンツタイプ：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:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
<!-- 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>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- 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>
</grammar> --break
</grammar> - ブレイク
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.
サーバーの認識結果データは、認識コンプリートイベントのMRCPメッセージ本文またはMIMEエンティティとしてのGet-result Responseメッセージに掲載されています。すべてのメディアサーバーは、認識結果をクライアントに戻すためのデフォルトの標準としてW3Cの自然言語セマンティクスマークアップ言語（NLSML）[10]をサポートする必要があるため、MIMEタイプのアプリケーション/X-NLSMLをサポートする必要があります。
Example 1: Content-Type:application/x-nlsml Content-Length:104
例1：コンテンツタイプ：アプリケーション/X-NLSMLコンテンツレングス：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>
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のリダイレクトを発行したためかもしれません。ここで、最初の認識者は、その認識中に音響およびその他のデータを収集した可能性があります。認識サーバーを切り替えると、このデータを通信することにより、2番目の認識サーバーが以前の認識者によって収集された音響データに基づいてより良い認識を提供することができます。このデータブロックはベンダー固有のものであり、メッセージの本体にMIMEタイプのアプリケーション/オクテットとして運ばれる必要があります。
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エンティティとして、メッセージ本文のベンダー固有のコンテキストブロックを返す必要があります。Content-ID値は、Get-Params応答のRecoldizer-Contextブロックヘッダーフィールドにも指定する必要があります。このベンダー固有のデータの提供を希望するSet-Paramsは、Get-Paramsから受け取ったコンテンツIDと同じMime Entityとしてメッセージ本体に送信する必要があります。Content-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メソッドのパラメーターの多くは、認識方法などの別の方法でも使用できます。しかし、違いは、セットパラムを使用して感度レベルのようなものを設定すると、該当する場合はいつでも、すべての将来のリクエストに適用されることです。一方、認識要求で感度レベルを渡すと、そのリクエストにのみ適用されます。
Example: C->S:SET-PARAMS 543256 MRCP/1.0 Sensitivity-Level:20 Recognition-Timeout:30 Confidence-Threshold:85
S->C:MRCP/1.0 543256 200 COMPLETE
S-> C：MRCP/1.0 543256 200完全
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ベストリストの長さなどの現在のデフォルトパラメーターについて認識者リソースを要求します。クライアントは、サーバーから送信して、サーバーから特定のパラメーターを要求できます値のない1つ以上の空のパラメーターヘッダー。サーバーは、それらの特定のパラメーターのみの設定のみを返す必要があります。クライアントが空のパラメーターヘッダーの特定のリストを送信しない場合、承認者はすべてのパラメーターの設定を返す必要があります。ベンダーに応じて、設定可能なパラメーターの数が大きくなる可能性があるため、ワイルドカードの使用は非常に集中的です。したがって、クライアントはWildCard 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完全な感度レベル：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.
クライアントからサーバーまでの定義文法メソッドは、文法を提供し、必要に応じて定義し、ダウンロードし、文法をコンパイルするようにサーバーに指示します。
If the server resource is in the recognition state, the DEFINE-GRAMMAR request MUST respond with a failure status.
サーバーリソースが認識状態にある場合、定義文法要求は障害ステータスで応答する必要があります。
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.
Example:
C->S:DEFINE-GRAMMAR 543257 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
<!-- 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>
</grammar>
</grammar>
S->C:MRCP/1.0 543257 200 COMPLETE Completion-Cause:000 success
S-> c：MRCP/1.0 543257 200完全な完了後：000成功
C->S:DEFINE-GRAMMAR 543258 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:helpgrammar@root-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
</grammar>
</grammar>
S->C:MRCP/1.0 543258 200 COMPLETE Completion-Cause:000 success
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"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
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
<?xml version="1.0"?>
<grammar xml:lang="en">
<import uri="session:politeness@form-level.store"
name="polite"/>
<rule id="basicCmd" scope="public">
<example> please move the window </example>
<example> open a file </example>
<ruleref import="polite#startPolite"/>
<ruleref uri="#command"/>
<ruleref import="polite#endPolite"/>
</rule>
<rule id="command">
<ruleref uri="#action"/> <ruleref uri="#object"/>
</rule>
<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>
<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>
</rule>
</rule>
</grammar>
</grammar>
S->C:MRCP/1.0 543259 200 COMPLETE Completion-Cause:000 success
S-> c：MRCP/1.0 543259 200完全な完了義理：000成功
C->S:RECOGNIZE 543260 MRCP/1.0
N-Best-List-Length:2
Content-Type:text/uri-list
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：MRCP/1.0 543260 200入力
S->C:START-OF-SPEECH 543260 IN-PROGRESS MRCP/1.0
S-> C：スピーチの開始543260 In-ProgressMRCP/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
<?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.
クライアントからサーバーへの認識方法は、認識を開始するように認識者に指示し、一致する文法を提供します。認識方法は、認識者が提供する結果の感度、信頼レベル、および詳細レベルを制御するためのパラメーターを運ぶことができます。これらのパラメーターは、以前の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.
リソースがアイドル状態にあり、認識を正常に開始できた場合、サーバーは成功コードと進行中の要求状態を返す必要があります。これは、認識者がアクティブであり、クライアントがこのリクエスト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.
認識者のリソースの場合、これが進行中のリクエスト状態を返すことができる唯一のリクエストです。つまり、認識が進行中です。認識が文法の代替品の1つを一致させるか、一致しないタイムアウトまたは他の理由で認識が完了すると、認識の結果とのリクエスト状態の結果、認識者リソースにクライアントに認識を完了するイベントをクライアントに送信する必要があります。完了。
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.
コンパイルに長い時間がかかる可能性のある大規模な文法の場合、繰り返し使用される文法の場合、クライアントは事前に文法で定義のリクエストを発行することができます。そのような場合、クライアントは認識要求を発行し、「セッション：」特別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.
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
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
<!-- 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>
</grammar>
</grammar>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
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
<?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 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).
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
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
<!-- 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>
</grammar>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
C->S:STOP 543258 200 MRCP/1.0
S->C:MRCP/1.0 543258 200 COMPLETE
Active-Request-Id-List: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リクエストは、異なる信頼性のwhold、またはn-best-list-lengthなどの制約を指定することができます。この機能はオプションであり、自動音声認識（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
<?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>
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.
これは、認識者からクライアントへのイベントであり、スピーチが検出されたことを示しています。このイベントは、シンセサイザーのリソースが認識者リソースとは異なるセッションにある場合、そのため、着信オーディオソースを認識していない場合に、バージオンオンのシナリオを実装するのに役立ちます。これらの場合、クライアントはプロキシとして行動し、向きを変えてシンセサイザーのリソースにバージに入れられた方法を発行することです。また、認識者リソースは、このイベントのヘッダーにユニークなプロキシシンク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.
このリクエストは、クライアントから認識リソースに送信されます。これは、認識エンジンとシンセサイザーエンジンが同じセッションにない場合に役立ちます。ここでは、バージュインプロンプトが再生されている場合、認識要求を同時にアクティブにして、バージオンキルインを検出および実装できるようにします。しかし同時に、プロンプトが終了するまで、認識者が入力なしタイマーを起動することは望ましくありません。認識要求のパラメーター認識者スタートタイマーヘッダーフィールドにより、クライアントはタイマーを開始するかどうかを言うことができます。クライアントが認識スタートタイマーの方法を認識者に送信するまで、認識者はタイマーを起動しないでください。
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のリクエストが完了したことを示す完全でなければなりません。承認者のコンテキストは、次の認識要求が発行されるまで、結果とその認識のオーディオ波形入力を依然として保持します。オーディオ波形のURLは、認識コンプリートイベントで波形-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
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
<!-- 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>
</grammar>
</grammar>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S-> c：MRCP/1.0 543257 200入力
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S-> C：スピーチの開始543257 In-ProgressMRCP/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
<?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.
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.
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
Content-Length: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
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
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
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
An ANNOUNCE message with the MRCP SPEAK request initiates speech.
MRCP Speak Requestがスピーチを開始するアナウンスメッセージ。
C->S:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:4
Session:12345678
Content-Type:application/mrcp
Content-Length:456
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>
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
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
MRCP/1.0 543257 200 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
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 Speech-Marker：Stephanie C-> s：RTSP/1.0 200 OK CSEQ：5
The synthesizer finishes with the SPEAK request.
S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:6
Session:12345678
Content-Type:application/mrcp
Content-Length:123
SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0
Speak-Complete 543257完全なMRCP/1.0
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
RECOGNIZE 543258 MRCP/1.0 Content-Type:application/grammar+xml Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="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>
</grammar>
</grammar>
S->C:RTSP/1.0 200 OK
CSeq:7
Content-Type:application/mrcp
Content-Length:123
MRCP/1.0 543258 200 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).
C->S:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:8 Session:12345678 Content-Type:application/mrcp
Content-Length:733
SPEAK 543259 MRCP/1.0 Kill-On-Barge-In:true Content-Type:application/synthesis+ssml Content-Length:104
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>
S->C:RTSP/1.0 200 OK
CSeq:8
Content-Type:application/mrcp
Content-Length:123
MRCP/1.0 543259 200 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.
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イベントを取得する前に、さらにいくつかのメッセージを受け取るでしょう。シンセサイザーと認識者が同じセッションにあるかどうかにかかわらず、認識者はクライアントにスピーチの開始イベントを生成する必要があります。
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.
その後、クライアントは盲目的に向きを変えて、シンセサイザーリソースに不器用な方法を発行する必要があります。シンセサイザーは、現在のSPEAKリクエストでKill-on-Barge-Inが有効になった場合、それを中断し、クライアントにSpeak Completeイベントを発行しました。この例では、シンセサイザーと認識者は同じセッションにあるため、クライアントはシンセサイザーに脱出した方法を発行せず、同じセッションの2つのリソースの間にKill-on-Barge-inが実装されたと仮定しました。そして働いた。
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
START-OF-SPEECH 543258 IN-PROGRESS MRCP/1.0
スピーチの開始543258 In-Progress MRCP/1.0
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
SPEAK-COMPLETE 543259 COMPLETE MRCP/1.0 Completion-Cause:000 normal
Speak-Complete 543259完全なMRCP/1.0 Reftilement-Caus：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.
認識リソースは、音声ストリームを文法と一致させ、結果を生成しました。認識の結果は、認識完了イベントの一部としてサーバーによって返されます。
S->C:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0
CSeq:11
Session:12345678
Content-Type:application/mrcp
Content-Length: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
認識完了543258 Complete MRCP/1.0 Reftional-Caus：000 Success Waveform-url：http：//web.media.com/session123/audio.wav content-type：application/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>
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
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
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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk。H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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.、Rao、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] Crocker、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and 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] World Wide Web Consortium、「Voice Extensible Markup Language（VoiceXML）バージョン2.0」、W3C候補の推奨、2004年3月。
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[7] Resnick、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[9] World Wide Web Consortium, "Speech Synthesis Markup Language (SSML) Version 1.0", W3C Candidate Recommendation, September 2004.
[9] World Wide Webコンソーシアム、「音声合成マークアップ言語（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] World Wide Webコンソーシアム、「音声インターフェイスフレームワークの自然言語セマンティクスマークアップ言語（NLSML）」、W3Cワーキングドラフト、2001年5月30日。
[11] World Wide Web Consortium, "Speech Recognition Grammar Specification Version 1.0", W3C Candidate Recommendation, March 2004.
[11]
[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] Freed、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] Levinson、E。、「コンテンツIDおよびメッセージ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]
[16] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[16]
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
CHAR = %x01-7F ; any 7-bit US-ASCII character,
; excluding NUL
CR = %x0D ; carriage return
CRLF = CR LF ; Internet standard newline
DIGIT = %x30-39 ; 0-9
DQUOTE = %x22 ; " (Double Quote)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09 ; horizontal tab
LF = %x0A ; linefeed
OCTET = %x00-FF ; 8 bits of data
SP = %x20 ; space
WSP = SP / HTAB ; white space
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
param = *pchar
quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
QUOTED-STRING = SWS DQUOTE *（QDTEXT / QUOTED-PAIR）DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
QUOTED-PAIR = "\"（％x00-09 /％x0b-0c /％x0e-7f）
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
/ "+" / "$" / ","
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
unreserved = alphanum / mark
char = unreserved / escaped /
":" / "@" / "&" / "=" / "+" / "$" / ","
alphanum = ALPHA / DIGIT
escaped = "%" HEXDIG HEXDIG
Escaped = "％" hexdig hexdig
absoluteURI = scheme ":" ( hier-part / opaque-part )
relativeURI = ( net-path / abs-path / rel-path )
[ "?" query ]
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
net-path = "//" authority [abs-path]
abs-path = "/" path-segments
abs-path = "/" path-segments
rel-path = rel-segment [ abs-path ]
rel-path = rel-segment [abs-path]
rel-segment = 1*( unreserved / escaped / ";" / "@"
/ "&" / "=" / "+" / "$" / "," )
opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":"
/ "@" / "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
path-segments = segment *（ "/"セグメント）
segment = *pchar *( ";" param )
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
userinfo = ( user ) [ ":" password ] "@"
user = 1*( unreserved / escaped
/ user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";"
/ "?" / "/"
password = *( unreserved / escaped /
"&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" )
alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
ipv6Address = hexpart ["：" ipv4address]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::"
[ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*DIGIT
generic-message = start-line message-header CRLF [ message-body ]
generic-message = start-line message-header crlf [message-body]
message-body = *OCTET
start-line = request-line / status-line / event-line
request-line = method-name SP request-id SP mrcp-version CRLF
request-line = method-name sp request-id sp mrcp-version crlf
status-line = mrcp-version SP request-id SP status-code SP request-state CRLF
event-line = event-name SP request-id SP request-state SP mrcp-version CRLF
event-line = event-name sp request-id sp request-state sp mrcp-version crlf
message-header = 1*(generic-header / resource-header)
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
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
request-id = 1*DIGIT
status-code = 1*DIGIT
active-request-id-list = "Active-Request-Id-List" ":"
request-id *("," request-id) CRLF
proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF
content-length = "Content-Length" ":" 1*DIGIT CRLF
content-base = "Content-Base" ":" absoluteURI CRLF
content-type = "Content-Type" ":" media-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
content-coding = token
content-location = "Content-Location" ":" ( absoluteURI / relativeURI ) CRLF
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
logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF
resource-header = recognizer-header / synthesizer-header
Resource-Header = Recoldizer-Header / Synthesizer-Header
method-name = synthesizer-method / recognizer-method
method-name = synthesizer-method / rucledizer-method
event-name = synthesizer-event / recognizer-event
event-name = synthesizer-event / raudeizer-event
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
request-state = "complete" / "in-progress" / "pending"
synthesizer-method = "SET-PARAMS"
/ "GET-PARAMS"
/ "SPEAK"
/ "STOP"
/ "PAUSE"
/ "RESUME"
/ "BARGE-IN-OCCURRED"
/ "CONTROL"
synthesizer-event = "SPEECH-MARKER" / "SPEAK-COMPLETE"
Synthesizer-Event = "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
recognizer-method = "SET-PARAMS"
/ "GET-PARAMS"
/ "DEFINE-GRAMMAR"
/ "RECOGNIZE"
/ "GET-RESULT"
/ "RECOGNITION-START-TIMERS"
/ "STOP"
recognizer-event = "START-OF-SPEECH" / "RECOGNITION-COMPLETE"
reademizer-event = "Startof-Speech" / "認識-Complete"
recognizer-header = confidence-threshold
/ sensitivity-level
/ speed-vs-accuracy
/ n-best-list-length
/ 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
speech-length-value = numeric-speech-length / text-speech-length
Speech-Length-Value =数値スピーチの長さ /テキストスピーチの長さ
text-speech-length = 1*ALPHA SP "Tag"
numeric-speech-length =("+" / "-") 1*DIGIT SP
numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
delta-seconds = 1*DIGIT
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF
boolean-value = "true" / "false"
speaker-profile = "Speaker-Profile" ":" absoluteURI CRLF
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
1*ALPHA CRLF
voice-parameter = "Voice-" voice-param-name ":" voice-param-value CRLF
Voice-Parameter = "Voice-" Voice-Param-Name "：" Voice-Param-Value CRLF
voice-param-name = 1*ALPHA
voice-param-value = 1*alphanum
prosody-parameter = "Prosody-" prosody-param-name ":" prosody-param-value CRLF
prody-parameter = "prody-" prosody-param-name "：" prosody-param-value crlf
prosody-param-name = 1*ALPHA
prosody-param-value = 1*alphanum
vendor-specific = "Vendor-Specific-Parameters" ":" vendor-specific-av-pair *[";" vendor-specific-av-pair] CRLF
Vendor-specific = "ベンダー固有のパラメーター" "："ベンダー固有のav-pair *[";"ベンダー固有のav-pair] crlf
vendor-specific-av-pair = vendor-av-pair-name "=" vendor-av-pair-value
ベンダー特有のav-pair = vendor-av-pair-name "=" vendor-av-pair-value
vendor-av-pair-name = 1*ALPHA
vendor-av-pair-value = 1*alphanum
speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF
speech-language = "Speech-Language" ":" 1*ALPHA CRLF
fetch-hint = "Fetch-Hint" ":" 1*ALPHA CRLF
audio-fetch-hint = "Audio-Fetch-Hint" ":" 1*ALPHA CRLF
fetch-timeout = "Fetch-Timeout" ":" 1*DIGIT CRLF
failed-uri = "Failed-URI" ":" absoluteURI CRLF
failed-uri-cause = "Failed-URI-Cause" ":" 1*ALPHA CRLF
speak-restart = "Speak-Restart" ":" boolean-value CRLF
speak-length = "Speak-Length" ":" speech-length-value
CRLF
confidence-threshold = "Confidence-Threshold" ":"
1*DIGIT CRLF
sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 1*DIGIT CRLF
n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
waveform-url = "Waveform-URL" ":" absoluteURI CRLF
recognizer-context-block = "Recognizer-Context-Block" ":" 1*ALPHA CRLF
Recoldizer-context-block = "radeizer-context-block" "：" 1*alpha crlf
recognizer-start-timers = "Recognizer-Start-Timers" ":" boolean-value CRLF
Recoldizer-Start-Timers = "Recoldizer-Start-Timers" "：" boolean-value crlf
speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*DIGIT CRLF
Speech-CompleteTimeOut = "Speech-CompleteTimeout" "：" 1*digit crlf
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*DIGIT CRLF
Speech-Incomplete-Timeout = "Speech-IntextreteTimeout" "：" 1*digit crlf
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*DIGIT CRLF
dtmf-interdigit-timeout = "dtmf-interdigit-timeout" "：" 1*digit crlf
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
dtmf-term-char = "DTMF-Term-Char" ":" CHAR CRLF
save-waveform = "Save-Waveform" ":" boolean-value CRLF
new-audio-channel = "New-Audio-Channel" ":" boolean-value CRLF
new-audio-channel = "new-audio-channel" "：" boolean-value crlf
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)
Authors' Addresses
著者のアドレス
Saravanan Shanmugham Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134
Saravanan Shanmugham Cisco Systems、Inc。170 W. Tasman Drive San Jose、CA 95134
EMail: sarvi@cisco.com
Peter Monaco Nuasis Corporation 303 Bryant St. Mountain View, CA 94041
Peter Monaco Nuasis Corporation 303 Bryant St. Mountain View、CA 94041
EMail: peter.monaco@nuasis.com
Brian Eberman Speechworks, Inc. 695 Atlantic Avenue Boston, MA 02111
EMail: brian.eberman@speechworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
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.
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.
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。