RFC4463 日本語訳
4463 A Media Resource Control Protocol (MRCP) Developed by Cisco,Nuance, and Speechworks. S. Shanmugham, P. Monaco, B. Eberman. April 2006. (Format: TXT=176385 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Shanmugham
Request for Comments: 4463 Cisco Systems, Inc.
Category: Informational P. Monaco
Nuance Communications
B. Eberman
Speechworks Inc.
April 2006
Shanmughamがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4463年のシスコシステムズInc.カテゴリ: 情報のP.のニュアンスコミュニケーションB.Eberman Speechworks株式会社モナコ2006年4月
A Media Resource Control Protocol (MRCP)
Developed by Cisco, Nuance, and Speechworks
シスコ、ニュアンス、および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)インターネット協会(2006)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配布しているプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実装と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
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'を使用することに注意してください。 しかしながら、このスペースでの進行中の標準化への先祖としてのこのドキュメントの歴史的な価値で、このドキュメントの公表は重要になります。
Shanmugham, et al. Informational [Page 1] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[1ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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.
このドキュメントはシスコシステムズInc.によって共同で開発されたメディアResource Controlプロトコル(MRCP)について説明します、Nuance Communications、そして、Speechworks Inc.Itがこの領域でのさらなる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コントロールメディアはリソースを修理します。 このプロトコルは、RTSP(本当のTime Streamingプロトコル)やSIP(セッションInitiationプロトコル)のようなストリーミングのプロトコルとRTP(本当のTimeプロトコル)のようなメディア排紙機構で働くように設計されています。SIPはデバイスを流す外部のメディアにコントロール接続を確立するのを助けます。
Table of Contents
目次
1. Introduction ....................................................3
2. Architecture ....................................................4
2.1. Resources and Services .....................................4
2.2. Server and Resource Addressing .............................5
3. MRCP Protocol Basics ............................................5
3.1. Establishing Control Session and Media Streams .............5
3.2. MRCP over RTSP .............................................6
3.3. Media Streams and RTP Ports ................................8
4. Notational Conventions ..........................................8
5. MRCP Specification ..............................................9
5.1. Request ...................................................10
5.2. Response ..................................................10
5.3. Event .....................................................12
5.4. Message Headers ...........................................12
6. Media Server ...................................................19
6.1. Media Server Session ......................................19
7. Speech Synthesizer Resource ....................................21
7.1. Synthesizer State Machine .................................22
7.2. Synthesizer Methods .......................................22
7.3. Synthesizer Events ........................................23
7.4. Synthesizer Header Fields .................................23
7.5. Synthesizer Message Body ..................................29
7.6. SET-PARAMS ................................................32
7.7. GET-PARAMS ................................................32
7.8. SPEAK .....................................................33
7.9. STOP ......................................................34
7.10. BARGE-IN-OCCURRED ........................................35
7.11. PAUSE ....................................................37
7.12. RESUME ...................................................37
7.13. CONTROL ..................................................38
7.14. SPEAK-COMPLETE ...........................................40
1. 序論…3 2. アーキテクチャ…4 2.1. リソースとサービス…4 2.2. サーバとリソースアドレシング…5 3. MRCPは基礎について議定書の中で述べます…5 3.1. コントロールセッションとメディアを確立するのは流れます…5 3.2. RTSPの上のMRCP…6 3.3. メディアストリームとRTPポート…8 4. 記号法のコンベンション…8 5. MRCP仕様…9 5.1. 要求します。10 5.2. 応答…10 5.3. イベント…12 5.4. メッセージヘッダー…12 6. メディアサーバ…19 6.1. メディアサーバセッション…19 7. スピーチシンセサイザリソース…21 7.1. シンセサイザ州のマシン…22 7.2. シンセサイザメソッド…22 7.3. シンセサイザイベント…23 7.4. シンセサイザヘッダーフィールド…23 7.5. シンセサイザメッセージ本体…29 7.6. セット-PARAMS…32 7.7. PARAMSを手に入れます…32 7.8. 話してください…33 7.9. 止まってください…34 7.10. 起こるところではしけで運んでください…35 7.11. 止まってください…37 7.12. 再開してください…37 7.13. 制御してください…38 7.14. 言葉の完全…40
Shanmugham, et al. Informational [Page 2] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[2ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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
7.15. スピーチマーカー…41 8. スピーチ認識器リソース…42 8.1. 認識器州のマシン…42 8.2. 認識器メソッド…42 8.3. 認識器イベント…43 8.4. 認識器ヘッダーフィールド…43 8.5. 認識器メッセージボディー…51 8.6. セット-PARAMS…56 8.7. PARAMSを手に入れます…56 8.8. 文法を定義します…57 8.9. 認識します。60 8.10. 止まってください…63 8.11. 結果を得ます…64 8.12. スピーチの始まり…64 8.13. 認識スタートタイマ…65 8.14. RECOGNITON完全…65 8.15. DTMF検出…67 9. 今後の研究…67 10. セキュリティ問題…67 11. RTSPベースの例…67 12. 有益な参照…74 付録A.ABNFメッセージ定義…76 付録B.承認…84
1. Introduction
1. 序論
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.
メディアResource Controlプロトコル(MRCP)は、ネットワークに関する処理リソースを制御するためにオーディオ/ビデオストリーム処理を必要とするクライアントデバイスにメカニズムを供給するように設計されています。 リソースを処理するこれらのメディアはスピーチ認識器(通称Automaticスピーチ認識(ASR)エンジン)、スピーチシンセサイザ(通称スピーチへのText(TTS)エンジン)、ファックス、信号検出器であるかもしれませんなど。 MRCPは分配されたInteractive Voice Responseプラットホーム、例えば、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プロトコルは、コントロールセッションがサーバでどう確立されるかを扱わないで、セッションを確立して、維持するためにレアルTime Streamingプロトコル(RTSP)[2]を当てにします。 また、セッション制御プロトコルもクライアントからネットワークサーバまでのメディア接続を確立するのに原因となります。MRCPプロトコルとそのメッセージングは、Session記述プロトコル(SDP)[5]と同様のMIMEの種類としての持ち越されたRTSPか別のプロトコルになるように設計されています。
Shanmugham, et al. Informational [Page 3] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[3ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[8]で説明されるように本書では解釈されることであるべきですか?
2. Architecture
2. アーキテクチャ
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 ||
||------------------|| ||--------------------||
|--------------------| |----------------------|
|--------------------| ||------------------|| |----------------------| || 応用層|| ||--------------------|| ||------------------|| || TTS| ASR| ファックス|| || ASR/TTSアピ|| ||Plugin|Plugin|Plugin|| ||------------------|| || オン| オン| オン|| || MRCPコア|| || MRCP| MRCP| MRCP|| || プロトコル・スタック|| ||--------------------|| ||------------------|| || RTSPスタック|| || RTSPスタック|| || || ||------------------|| ||--------------------|| || TCP/IPスタック||========IP=========|| TCP/IPスタック|| ||------------------|| ||--------------------|| |--------------------| |----------------------|
MRCP client Real-time Streaming MRCP
media server
MRCPクライアントレアル-時間Streaming MRCPメディアサーバ
2.1. Resources and Services
2.1. リソースとサービス
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.
これらはある頻度のトーンと音を生成する信号発生器とパターンのようなリアルタイムのストリーム、および話されたオーディオストリームなどを生成するスピーチシンセサイザを生成することができるリソースです。
Shanmugham, et al. Informational [Page 4] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[4ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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ストリームを通してファックスを送るか、または受け止めることができます。
2.2. Server and Resource Addressing
2.2. サーバとリソースアドレシング
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,
Aメディアサーバかコンテナ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/メディア/speechrecognizer/rtsp://mediaserver.com/メディア/speechsynthesizer/rtsp://mediaserver.com/media/fax/
3. MRCP Protocol Basics
3. MRCPプロトコル基礎
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はリソース処理で制御して、交信する問題がストリームであると扱って、それをするのに必要である要求、応答、およびイベントを定義します。
3.1. Establishing Control Session and Media Streams
3.1. コントロールセッションとメディアストリームを確立します。
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
クライアントとサーバとのコントロールセッションは、RTSPのようなプロトコルを使用することで確立されます。 また、このプロトコルはサーバとクライアントの間の適切なRTPストリームをセットアップするでしょう、必要に応じてポートを割り当てて、輸送パラメタをセットアップして。 各コントロール
Shanmugham, et al. Informational [Page 5] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[5ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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プロトコルによると、セッションイドの形式、用法、およびライフサイクルがあります。 セッション中のリソースは個々のリソース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メッセージを提供します。 トンネリングMRCPメッセージにSIP[4]などの別のプロトコルを使用できました。
3.2. MRCP over RTSP
3.2. RTSPの上の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要求/応答をクライアントとサーバの間まで運ぶのにANNOUNCEメソッド/応答を使用しなければなりません。MRCPメッセージはRTSP SETUPかTEARDOWNメッセージで伝えられてはいけません。
Currently all RTSP messages are request/responses and there is no support for asynchronous events in RTSP. This is because RTSP was designed to work over TCP or UDP and, hence, could not assume reliability in the underlying protocol. Hence, when using MRCP over RTSP, an asynchronous event from the MRCP server is packaged in a server-initiated ANNOUNCE method/response communication. A future RTSP extension to send asynchronous events from the server to the client would provide an alternate vehicle to carry such asynchronous MRCP events from the server.
現在すべてのRTSPメッセージが要求/応答です、そして、非同期的なイベントのサポートが全くRTSPにありません。 これはRTSPがTCPかUDPの上で働くように設計されて、したがって、基本的なプロトコルの信頼性を仮定できなかったからです。 RTSPの上でMRCPを使用するとき、したがって、MRCPサーバからの非同期的なイベントはサーバで開始しているANNOUNCEメソッド/応答コミュニケーションでパッケージされます。 サーバからクライアントまでの非同期的なイベントを送る将来のRTSP拡張子は、サーバからそのような非同期なMRCPイベントを運ぶために代替の乗り物を提供するでしょう。
An RTSP session is created when an RTSP SETUP message is sent from the client to a server and is addressed to a server URL or any one of its resource URLs without specifying a session-id. The server will establish a session context and will respond with a session-id to the client. This sequence will also set up the RTP transport parameters between the client and the server, and then the server will be ready to receive or send media streams. If the client wants to attach an additional resource to an existing session, the client should send that session's ID in the subsequent SETUP message.
セッションイドを指定しないで、RTSPセッションをRTSP SETUPメッセージをクライアントからサーバに送るとき、作成して、サーバURLかリソースURLのいずれにも扱います。 サーバは、セッション文脈を確立して、セッションイドでクライアントに反応するでしょう。 また、この系列がクライアントとサーバの間のRTP輸送パラメタをセットアップして、サーバは、メディアストリームを、次に、受ける準備ができているか、送付にならせる準備ができているでしょう。クライアントが追加リソースを既存のセッションに添付したいなら、クライアントはその後のSETUPメッセージのそのセッションのIDを送るべきです。
Shanmugham, et al. Informational [Page 6] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[6ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
When a media server implementing MRCP over RTSP receives a PLAY, RECORD, or PAUSE RTSP method from an MRCP resource URL, it should respond with an RTSP 405 "Method not Allowed" response. For these resources, the only allowed RTSP methods are SETUP, TEARDOWN, DESCRIBE, and ANNOUNCE.
RTSPの上でMRCPを実装するメディアサーバがMRCPリソースURLからPLAY、RECORD、またはPAUSE RTSPメソッドを受けるとき、それはRTSP405「許容されなかったメソッド」応答で応じるべきです。 これらのリソースに関しては、唯一の許容RTSPメソッドが、SETUPと、TEARDOWNと、DESCRIBEと、ANNOUNCEです。
Example 1:
例1:
C->S: ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:4
Session:12345678
Content-Type:application/mrcp
Content-Length:223
C>S: ANNOUNCE rtsp://media.server.com/メディア/シンセサイザRTSP/1.0CSeq: 4Session: 12345678コンテントタイプ: mrcp Contentアプリケーション/長さ: 223
SPEAK 543257 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
543257MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C: RTSP/1.0 200 OK
CSeq: 4
Session:12345678
RTP-Info:url=rtsp://media.server.com/media/synthesizer;
seq=9810092;rtptime=3450012
Content-Type:application/mrcp
Content-Length:52
S>C: RTSP/1.0 200はCSeqを承認します: 4 セッション: 12345678 RTP-インフォメーション: url=rtsp://media.server.com/メディア/シンセサイザ。 seq=9810092; rtptime=3450012コンテントタイプ: mrcp Contentアプリケーション/長さ: 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
S>C: ANNOUNCE rtsp://media.server.com/メディア/シンセサイザRTSP/1.0CSeq: 6Session: 12345678
Shanmugham, et al. Informational [Page 7] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[7ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
Content-Type:application/mrcp
Content-Length:123
コンテントタイプ: mrcpアプリケーション/コンテンツの長さ: 123
SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0
言葉の完全な543257完全なMRCP/1.0
C->S: RTSP/1.0 200 OK
CSeq:6
C>S: RTSP/1.0 200OK 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メッセージが省かれます。
3.3. Media Streams and RTP Ports
3.3. メディアストリームとRTPポート
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.
スピーチ(TTS)エンジンへの自動音声認識(ASR)エンジンやテキストなどのマルチメディア処理リソースがただ一つのセッションに使用されるとき、1セットの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)識別子値を使用することによって差別化されたサーバに向かってマルチメディアストリームを送ることができます。 同様に、サーバは、1つ以上が存在しているなら独立駆動動力伝達装置リソースURLから発するメディアストリームを差別化するのに複数のSynchronized Source(SSRC)識別子値を使用できます。 他方では、個々のリソースは、ちょうど1つのストリームをクライアントに送るために一緒に働くかもしれません。 これはメディアサーバの実装まで達しています。
4. Notational Conventions
4. 記号法のコンベンション
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仕様のセクションX.Yについて言及します。(RFC2616[1])。
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]で使用されるそれと同様の増大しているBN記法(ABNF)の両方で説明されます。 それはRFC4234[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フォームの完全なメッセージ・フォーマットは、Appendix Aに供給されて、標準の形式定義です。
Shanmugham, et al. Informational [Page 8] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[8ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
5. MRCP Specification
5. MRCP仕様
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でISO10646文字集合を使用することで原文です。(多くの異なった言語が表されるのを許容するRFC3629[12])。 しかしながら、コンパクトな表現を助けるために、また、望まれていると、MRCPは、ISO8859-1などの他の文字集合が使用されるのを許容します。 MRCPプロトコルヘッダーとフィールド名はUTF-8の米国-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、受信機SHOULDによって終えられます。また、系列ターミネータとして自分たちで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メッセージには、要求/応答がどのリソースから/に来るかに関してアドレス指定情報がありません。 代わりに、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 ]
ジェネリックメッセージ=スタート系列メッセージヘッダーCRLF[メッセージ本体]
message-body = *OCTET
メッセージ本体=*OCTET
start-line = request-line / status-line / event-line
スタート系列イベント=要求系列/状況表示行/系列
The message-body contains resource-specific and message-specific data that needs to be carried between the client and server as a MIME entity. The information contained here and the actual MIME-types used to carry the data are specified later when addressing the specific messages.
メッセージ本体はMIME実体としてクライアントとサーバの間まで運ばれる必要があるリソース特有の、そして、メッセージ特有のデータを含んでいます。 後で特定のメッセージを扱うとき、ここに含まれた情報とデータを運ぶのに使用される実際のMIMEの種類は指定されます。
Shanmugham, et al. Informational [Page 9] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[9ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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の種類とコード化を示しながら、満足しているヘッダーを含むでしょう。
5.1. Request
5.1. 要求
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要求はゼロか、より多くのパラメタがメッセージヘッダーの一部としてあとに続いたRequest系列と要求メッセージに特定のデータを含む任意のメッセージ本体から成ります。
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メッセージは最初の系列の中に適用されるべきメソッド、その要求のためのメソッドタグ、および使用中のプロトコルのバージョンを含んでいます。
request-line = method-name SP request-id SP
mrcp-version CRLF
要求系列=メソッド名SP要求イドSP mrcp-バージョンCRLF
The request-id field is a unique identifier created by the client and sent to the server. The server resource should use this identifier in its response to this request. If the request does not complete with the response, future asynchronous events associated with this request MUST carry the request-id.
要求イド分野はクライアントによって作成されて、サーバに送られたユニークな識別子です。サーバリソースはこの要求への応答にこの識別子を使用するべきです。 応答で完全でなく要求するなら、この要求に関連している将来の非同期的なイベントは要求イドを運ばなければなりません。
request-id = 1*DIGIT
要求イド=1*DIGIT
The method-name field identifies the specific request that the client is making to the server. Each resource supports a certain list of requests or methods that can be issued to it, and will be addressed in later sections.
メソッド名前欄はクライアントがサーバにしている特定の要求を特定します。各リソースはそれに出すことができて、後のセクションで扱われる要求かメソッドのあるリストをサポートします。
method-name = synthesizer-method
/ recognizer-method
認識器メソッド名=シンセサイザメソッド/メソッド
The mrcp-version field is the MRCP protocol version that is being used by the client.
mrcp-バージョン分野はクライアントによって使用されているMRCPプロトコルバージョンです。
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
「mrcpバージョン="MRCP"」/、」 1*ケタ、」、」 1*ケタ
5.2. Response
5.2. 応答
After receiving and interpreting the request message, the server resource responds with an MRCP response message. It consists of a status line optionally followed by a message body.
要求メッセージを受け取って、解釈した後に、サーバリソースはMRCP応答メッセージで応じます。 それはメッセージ本体が任意にあとに続いた状況表示行から成ります。
response-line = mrcp-version SP request-id SP status-code SP
request-state CRLF
応答系列=mrcp-バージョンSP要求イドSPステータスコードSP要求州のCRLF
Shanmugham, et al. Informational [Page 10] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[10ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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-バージョン分野は、Request線で使用されるものと同様であり、サーバで動くMRCPプロトコルのバージョンを示します。
The request-id used in the response MUST match the one sent in the corresponding request message.
応答に使用される要求イドは対応する要求メッセージで送られたものに合わなければなりません。
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.
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.
request-state = "COMPLETE"
/ "IN-PROGRESS"
/ "PENDING"
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
5.2.1. Status Codes
5.2.1. Status Codes
The status codes are classified under the Success(2XX) codes and the Failure(4XX) codes.
The status codes are classified under the Success(2XX) codes and the Failure(4XX) codes.
5.2.1.1. Success 2xx
5.2.1.1. Success 2xx
200 Success
201 Success with some optional parameters ignored.
200 Success 201 Success with some optional parameters ignored.
5.2.1.2. Failure 4xx
5.2.1.2. Failure 4xx
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
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
Shanmugham, et al. Informational [Page 11] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 11] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
409 Unsupported Parameter Value
421-499 Resource specific Failure codes
409 Unsupported Parameter Value 421-499 Resource specific Failure codes
5.3. Event
5.3. Event
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.
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.
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.
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.
The request-id used in the event should match the one sent in the request that caused this event.
The request-id used in the event should match the one sent in the request that caused this event.
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.
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.
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.
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 / recognizer-event
5.4. Message Headers
5.4. Message Headers
MRCP header fields, which include general-header (Section 5.4) and
resource-specific-header (Sections 7.4 and 8.4), follow the same
generic format as that given in Section 2.1 of RFC 2822 [7]. Each
header field consists of a name followed by a colon (":") and the
field value. Field names are case-insensitive. The field value MAY
be preceded by any amount of linear whitespace (LWS), though a single
SP is preferred. Header fields can be extended over multiple lines
by preceding each extra line with at least one SP or HT.
MRCP 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.
Shanmugham, et al. Informational [Page 12] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 12] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
message-header = 1*(generic-header / resource-header)
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.
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)).
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.
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.
Generic Headers
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
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.
All headers in MRCP will be case insensitive, consistent with HTTP and RTSP protocol header definitions.
5.4.1. Active-Request-Id-List
5.4.1. Active-Request-Id-List
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.
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.
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
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
Shanmugham, et al. Informational [Page 13] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 13] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
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.
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.
The active-request-id-list is only used in requests and responses, not in events.
The active-request-id-list is only used in requests and responses, not in events.
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.
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-list = "Active-Request-Id-List" ":" request-id
*("," request-id) CRLF
active-request-id-list = "Active-Request-Id-List" ":" request-id *("," request-id) CRLF
5.4.2. Proxy-Sync-Id
5.4.2. Proxy-Sync-Id
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.
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.
proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF
proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF
5.4.3. Accept-Charset
5.4.3. Accept-Charset
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.
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.
Shanmugham, et al. Informational [Page 14] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 14] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
5.4.4. Content-Type
5.4.4. Content-Type
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.
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.
5.4.5. Content-Id
5.4.5. Content-Id
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.
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.
5.4.6. Content-Base
5.4.6. Content-Base
The content-base entity-header field may be used to specify the base URI for resolving relative URLs within the entity.
The content-base entity-header field may be used to specify the base URI for resolving relative URLs within the entity.
content-base = "Content-Base" ":" absoluteURI CRLF
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.
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.
5.4.7. Content-Encoding
5.4.7. Content-Encoding
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.
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-encoding = "Content-Encoding" ":" *WSP content-coding *(*WSP "," *WSP content-coding *WSP ) CRLF
content-coding = token
content-coding = token
Shanmugham, et al. Informational [Page 15] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 15] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
Content coding is defined in [H3.5]. An example of its use is
Content coding is defined in [H3.5]. An example of its use is
Content-Encoding:gzip
Content-Encoding:gzip
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.
5.4.8. Content-Location
5.4.8. Content-Location
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.
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.
content-location = "Content-Location" ":" ( absoluteURI /
relativeURI ) CRLF
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.
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.
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.
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.
If the content-location is a relative URI, the relative URI is interpreted relative to the content-base URI.
If the content-location is a relative URI, the relative URI is interpreted relative to the content-base URI.
5.4.9. Content-Length
5.4.9. Content-Length
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].
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].
Shanmugham, et al. Informational [Page 16] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 16] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
5.4.10. Cache-Control
5.4.10. Cache-Control
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.
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.
cache-control = "Cache-Control" ":" *WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )
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
cache-directive = "max-age" "=" delta-seconds / "max-stale" "=" delta-seconds / "min-fresh" "=" delta-seconds
delta-seconds = 1*DIGIT
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.
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.
These directives allow the media server to override the basic expiration mechanism.
max-age
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.
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.
min-fresh
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
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
Shanmugham, et al. Informational [Page 17] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 17] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
client wants the media server to use a response that will still be
fresh for at least the specified number of seconds.
client wants the media server to use a response that will still be fresh for at least the specified number of seconds.
max-stale
max-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.
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.
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.
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.
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.
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.
5.4.11. Logging-Tag
5.4.11. Logging-Tag
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.
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.
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 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.
logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF
logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF
Shanmugham, et al. Informational [Page 18] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 18] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
6. Media Server
6. Media Server
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.
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.
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.
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.
6.1. Media Server Session
6.1. Media Server Session
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.
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.
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.
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.
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.
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.
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.
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.
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
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
Shanmugham, et al. Informational [Page 19] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 19] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
headers (i.e., m-lines) to allow the client to provide the media server with more than one option to choose from.
headers (i.e., m-lines) to allow the client to provide the media server with more than one option to choose from.
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.
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.
Example:
Example:
C->S:
C->S:
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0
CSeq:1
Transport:RTP/AVP;unicast;client_port=46456-46457
Content-Type:application/sdp
Content-Length:190
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0 CSeq:1 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
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
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
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
Shanmugham, et al. Informational [Page 20] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 20] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
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.
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.
C->S:
C->S:
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0
CSeq:1
Transport:RTP/AVP;unicast;client_port=46498
SETUP rtsp://media.server.com/recognizer/ RTSP/1.0 CSeq:1 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
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
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
7. Speech Synthesizer Resource
7. Speech Synthesizer Resource
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.
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.
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.
Shanmugham, et al. Informational [Page 21] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 21] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
7.1. Synthesizer State Machine
7.1. Synthesizer State Machine
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.
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.
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--------------------------|
活動していない話しは州の州の状態をポーズしました。| | | |----------話してください。------->| |--------| | <、-、-、-、-、--停止------------| コントロール| | <、-、-、--言葉の完全です。----| |、-、-、-、-、-、--、>| | <、-、-、--中ではしけで運ぶほど起こる、-| | | |--------| | | コントロール|-----------くぎり--------->|、| |、-、-、-、-、-、--、>| <、-、-、-、-、-、-、-、-、--履歴書---------| | | |----------| | | くぎり| | | |、-、-、-、-、-、-、-、--、>|、| |--------|----------| | | 起こるところではしけで運んでください。| スピーチマーカー| | |、-、-、-、-、-、--、>| <、-、-、-、-、-、-、-、--、|、| |----------| | |------------| | 停止| 話してください。| | | | |、-、-、-、-、-、-、-、-、-、--、>| | <、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--停止--------------------------|
7.2. Synthesizer Methods
7.2. シンセサイザメソッド
The synthesizer supports the following methods.
シンセサイザは以下のメソッドをサポートします。
synthesizer-method = "SET-PARAMS"
/ "GET-PARAMS"
/ "SPEAK"
/ "STOP"
/ "PAUSE"
/ "RESUME"
/ "BARGE-IN-OCCURRED"
/ "CONTROL"
シンセサイザメソッドが「設定PARAMS」/と等しい、「」 /が「話す」か、または「止まる」というPARAMSを手に入れている/「くぎり」/「履歴書」/「起こるところのはしけ」/「コントロール」
Shanmugham, et al. Informational [Page 22] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[22ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.3. Synthesizer Events
7.3. シンセサイザイベント
The synthesizer may generate the following events.
シンセサイザは以下のイベントを生成するかもしれません。
synthesizer-event = "SPEECH-MARKER"
/ "SPEAK-COMPLETE"
シンセサイザイベント=「スピーチマーカー」/「言葉の完全です」。
7.4. Synthesizer Header Fields
7.4. シンセサイザヘッダーフィールド
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.
シンセサイザメッセージはそれが関連しているメッセージのRequest、Response、またはEventを増大させる要求オプションと情報を含むヘッダーフィールドを含むかもしれません。
synthesizer-header = jump-target ; Section 7.4.1
/ kill-on-barge-in ; Section 7.4.2
/ speaker-profile ; Section 7.4.3
/ completion-cause ; Section 7.4.4
/ voice-parameter ; Section 7.4.5
/ prosody-parameter ; Section 7.4.6
/ vendor-specific ; Section 7.4.7
/ speech-marker ; Section 7.4.8
/ speech-language ; Section 7.4.9
/ fetch-hint ; Section 7.4.10
/ audio-fetch-hint ; Section 7.4.11
/ fetch-timeout ; Section 7.4.12
/ failed-uri ; Section 7.4.13
/ failed-uri-cause ; Section 7.4.14
/ speak-restart ; Section 7.4.15
/ speak-length ; Section 7.4.16
シンセサイザヘッダーはジャンプ目標と等しいです。 中のはしけにおけるセクション7.4.1/獲物。 セクション7.4スピーカー.2/プロフィール。 セクション7.4完成.3/原因。 セクション7.4声.4/パラメタ。 セクション7.4音律.5/パラメタ。 ベンダーセクション7.4.6/特有。 セクション7.4のスピーチ.7/マーカー。 セクション7.4スピーチ.8/言語。 セクション7.4フェッチ.9/ヒント。 セクション7.4オーディオフェッチ.10/ヒント。 セクション7.4フェッチ.11/タイムアウト。 セクション7.4の失敗した.12/uri。 セクション7.4の失敗したuri.13/原因。 再開をセクション7.4.14/話します。 長さをセクション7.4.15/話します。 セクション7.4 .16
Parameter Support Methods/Events/Response
パラメタサポートメソッド/イベント/応答
jump-target MANDATORY SPEAK, CONTROL
logging-tag MANDATORY SET-PARAMS, GET-PARAMS
kill-on-barge-in MANDATORY SPEAK
speaker-profile OPTIONAL SET-PARAMS, GET-PARAMS,
SPEAK, CONTROL
completion-cause MANDATORY SPEAK-COMPLETE
voice-parameter MANDATORY SET-PARAMS, GET-PARAMS,
SPEAK, CONTROL
prosody-parameter MANDATORY SET-PARAMS, GET-PARAMS,
SPEAK, CONTROL
vendor-specific MANDATORY SET-PARAMS, GET-PARAMS
speech-marker MANDATORY SPEECH-MARKER
speech-language MANDATORY SET-PARAMS, GET-PARAMS, SPEAK
fetch-hint MANDATORY SET-PARAMS, GET-PARAMS, SPEAK
audio-fetch-hint MANDATORY SET-PARAMS, GET-PARAMS, SPEAK
fetch-timeout MANDATORY SET-PARAMS, GET-PARAMS, SPEAK
MANDATORY SPEAKをジャンプして狙ってください、CONTROL伐採タグMANDATORY SET-PARAMS、GET-PARAMS中のはしけにおける獲物MANDATORY SPEAKスピーカープロフィールOPTIONAL SET-PARAMS、GET-PARAMS、SPEAK、CONTROL完成原因MANDATORY SPEAK-COMPLETE声パラメタMANDATORY SET-PARAMS、GET-PARAMS、SPEAK、CONTROL音律パラメタMANDATORY SET-PARAMS; GET-PARAMS、SPEAK、CONTROLのベンダー特有のMANDATORY SET-PARAMS、GET-PARAMSスピーチマーカーMANDATORY SPEECH-MARKERスピーチ言語MANDATORY SET-PARAMS、GET-PARAMS、SPEAKはMANDATORY SET-PARAMSをフェッチでほのめかします、GET-PARAMS、SPEAKオーディオフェッチヒントMANDATORY SET-PARAMS、GET-PARAMS、SPEAKフェッチタイムアウトMANDATORY SET-PARAMS、GET-PARAMS、SPEAK
Shanmugham, et al. Informational [Page 23] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[23ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
failed-uri MANDATORY Any
failed-uri-cause MANDATORY Any
speak-restart MANDATORY CONTROL
speak-length MANDATORY SPEAK, CONTROL
再開を話している失敗したuri MANDATORY Anyの失敗したuri原因MANDATORY Any MANDATORY CONTROL長さを話しているMANDATORY SPEAK、CONTROL
7.4.1. Jump-Target
7.4.1. ジャンプ目標
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".
このパラメタは、活発なSPEAK要求のときにCONTROLメソッドで指定されるかもしれなくて、後方に前方へ動くか、または巻き戻すジャンプサイズを制御します。 または、A+、--現在プレーされていることに相対的価値を示します。 これはSPEAKが基づいて話し始めるべきであるよう要求するスピーチマークアップにオフセットを示すというSPEAK要求で指定されるかもしれません。 ユニットがサポートした異なったスピーチの長さはシンセサイザ実装に依存しています。 ユニットか操作をサポートしないなら、リソースSHOULDは「不法入国者かUnsupportedがパラメタのために評価する」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"
「ジャンプ目標=「ジャンプサイズ」」:、」 1*アルファーSP「タグ」数値スピーチ長さ=(「+」/「-」)の1*ケタのSPの数値スピーチ単位の数値スピーチテキストスピーチの数値スピーチの長さ/長さのテキストスピーチのスピーチ長さの価値のCRLFスピーチ長さの価値=長さ=単位は「2番目」/「Word」/「文」/「パラグラフ」と等しいです。
7.4.2. Kill-On-Barge-In
7.4.2. 中ではしけの上で殺してください。
This parameter MAY BE sent as part of the SPEAK method to enable kill-on-barge-in support. If enabled, the SPEAK method is interrupted by DTMF input detected by a signal detector resource or by the start of speech sensed or recognized by the speech recognizer resource.
中のはしけにおける獲物サポートを可能にするSPEAKメソッドの一部としてこのパラメタを送るかもしれません。 可能にされるなら、SPEAKメソッドは信号検出器リソースによって検出されたDTMF入力かスピーチ認識器リソースによって感じられるか、または認識されたスピーチの始まりで中断されます。
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF
boolean-value = "true" / "false"
「中のはしけにおける獲物は「中ではしけの上で殺してください」と等しい」:、」 「本当である」か「誤っていた」状態でCRLFブール値=を論理演算子で評価してください。
If the recognizer or signal detector resource is on, the same server as the synthesizer, the server should be intelligent enough to recognize their interactions by their common RTSP session-id and work with each other to provide kill-on-barge-in support. The client needs to send a BARGE-IN-OCCURRED method to the synthesizer resource when it receives a barge-in-able event from the synthesizer resource
認識器か信号検出器リソースがオンです、シンセサイザと同じサーバ、サーバがそれらの一般的なRTSPセッションイドでそれらの相互作用を認識して、中のはしけにおける獲物サポートを提供するために互いと共に働くことができるくらい知的であるべきであるということであるなら。 クライアントは、それがシンセサイザリソースからできるところのはしけのイベントを受けるとき、BARGE IN OCCURREDメソッドをシンセサイザリソースに送る必要があります。
Shanmugham, et al. Informational [Page 24] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[24ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
or signal detector resource. These resources MAY BE local or distributed. If this field is not specified, the value defaults to "true".
または、探知器リソースに合図してください。 これらのリソースは、ローカルか分配されているかもしれません。 この分野が指定されないなら、値は「本当に」デフォルトとします。
7.4.3. Speaker Profile
7.4.3. 議長Profile
This parameter MAY BE part of the SET-PARAMS/GET-PARAMS or SPEAK request from the client to the server and specifies the profile of the speaker by a URI, which may be a set of voice parameters like gender, accent, etc.
このパラメタは、クライアントからサーバまでのSET-PARAMS/GET-PARAMSかSPEAK要求の一部であるかもしれなく、URIでスピーカーのプロフィールを指定します。(それは、性、アクセントなどのように1セットの声のパラメタであるかもしれません)。
speaker-profile = "Speaker-Profile" ":" uri CRLF
「スピーカープロフィールは「議長Profile」と等しい」:、」 uri CRLF
7.4.4. Completion Cause
7.4.4. 完成原因
This header field MUST be specified in a SPEAK-COMPLETE event coming from the synthesizer resource to the client. This indicates the reason behind the SPEAK request completion.
シンセサイザリソースからクライアントに来るSPEAK-COMPLETEイベントでこのヘッダーフィールドを指定しなければなりません。 これはSPEAK要求完成の後ろに理由を示します。
completion-cause = "Completion-Cause" ":" 1*DIGIT SP 1*ALPHA
CRLF
「完成原因は「完成原因」と等しい」:、」 1*ケタSP1*アルファ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.
通常、完成した原因コードCause-名前記述000の正常なSPEAK。 001 中でSPEAKが要求するはしけで運ぶのは、中ではしけで運ぶので、終えられました。 失敗を分析しているSPEAKが要求する002はスピーチマーク付けテキストを分析しないことで終わりました。 SPEAKが要求する003uri-失敗が終わった、URIの1つへのアクセスは失敗しました。 004 SPEAKが要求する誤りは早まって、シンセサイザ誤りのため終わりました。 言語サポートされないLanguageがサポートしなかった005。
7.4.5. Voice-Parameters
7.4.5. 声パラメタ
This set of parameters defines the voice of the speaker.
このセットのパラメタはスピーカーの声を定義します。
voice-parameter = "Voice-" voice-param-name ":"
voice-param-value CRLF
「声パラメタは「声」 声のparam名」と等しいです」 声のparam価値のCRLF
voice-param-name is any one of the attribute names under the voice element specified in W3C's Speech Synthesis Markup Language Specification [9]. The voice-param-value is any one of the value choices of the corresponding voice element attribute specified in the above section.
声のparam名はW3C's Speech Synthesis Markup Language Specification[9]で指定された声の要素の下における属性名のいずれでもあります。 声のparam価値は上のセクションで指定された対応する声の要素属性の値の選択のいずれでもあります。
Shanmugham, et al. Informational [Page 25] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[25ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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).
5月を全体のセッションのためにデフォルト値を定義するか、または得るというSET-PARAMS/GET-PARAMS要求で送るか、またはそれのためにデフォルト値を定義するというSPEAK要求で送るかもしれないこれらのヘッダーフィールドは要求を話します。 その上、これらの属性はSpeech Synthesis Markup Language(SSML)で値上げされたスピーチテキストの一部であるかもしれません。
These voice parameter header fields can also be sent in a CONTROL method to affect a SPEAK request in progress and change its behavior on the fly. If the synthesizer resource does not support this operation, it should respond back to the client with a status of unsupported.
また、進行中のSPEAK要求に影響して、急いで振舞いを変えるCONTROLメソッドでこれらの声のパラメタヘッダーフィールドを送ることができます。 シンセサイザリソースがこの操作をサポートしないなら、それはサポートされないことの状態でクライアントに応じて戻るべきです。
7.4.6. Prosody-Parameters
7.4.6. 音律パラメタ
This set of parameters defines the prosody of the speech.
このセットのパラメタはスピーチの音律を定義します。
prosody-parameter = "Prosody-" prosody-param-name ":"
prosody-param-value CRLF
「音律パラメタは「音律」 音律param名」と等しいです」 音律param価値のCRLF
prosody-param-name is any one of the attribute names under the prosody element specified in W3C's Speech Synthesis Markup Language Specification [9]. The prosody-param-value is any one of the value choices of the corresponding prosody element attribute specified in the above section.
音律param名はW3C's Speech Synthesis Markup Language Specification[9]で指定された音律要素の下における属性名のいずれでもあります。 音律param価値は上のセクションで指定された対応する音律要素属性の値の選択のいずれでもあります。
These header fields MAY BE sent in SET-PARAMS/GET-PARAMS request to define/get default values for the entire session or MAY BE sent in the SPEAK request to define default values for that speak request. Furthermore, these attributes can be part of the speech text marked up in SSML.
5月を全体のセッションのためにデフォルト値を定義するか、または得るというSET-PARAMS/GET-PARAMS要求で送るか、またはそれのためにデフォルト値を定義するという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かSPEAK要求における音律パラメタヘッダーフィールドは適用されます。
These prosody parameter header fields MAY also be sent in a CONTROL method to affect a SPEAK request in progress and to change its behavior on the fly. If the synthesizer resource does not support this operation, it should respond back to the client with a status of unsupported.
また、進行中のSPEAK要求に影響して、急いで振舞いを変えるCONTROLメソッドでこれらの音律パラメタヘッダーフィールドを送るかもしれません。 シンセサイザリソースがこの操作をサポートしないなら、それはサポートされないことの状態でクライアントに応じて戻るべきです。
Shanmugham, et al. Informational [Page 26] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[26ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.4.7. Vendor-Specific Parameters
7.4.7. ベンダー特有のパラメタ
This set of headers allows for the client to set vendor-specific parameters.
このセットのヘッダーは、クライアントがベンダー特有のパラメタを設定するのを許容します。
vendor-specific = "Vendor-Specific-Parameters" ":"
vendor-specific-av-pair
*[";" vendor-specific-av-pair] CRLF
「ベンダー特有の=「ベンダーの特定のパラメタ」」:、」 ベンダー特定のav組*、[「」、;、ベンダー特定のav組] CRLF
vendor-specific-av-pair = vendor-av-pair-name "="
vendor-av-pair-value
ベンダー特定のav組=ベンダーav組名「=」ベンダーav組価値
This header MAY BE sent in the SET-PARAMS/GET-PARAMS method and is used to set vendor-specific parameters on the server side. The vendor-av-pair-name can be any vendor-specific field name and conforms to the XML vendor-specific attribute naming convention. The vendor-av-pair-value is the value to set the attribute to and needs to be quoted.
このヘッダーは、SET-PARAMS/GET-PARAMSメソッドで送られるかもしれなくて、サーバ側のベンダー特有のパラメタを設定するのに使用されます。 ベンダーav組名は、どんなベンダー特有のフィールド名であることができも、XMLのベンダー特有の属性命名規則に従います。 ベンダーav組価値は、属性を設定する値であり、引用される必要があります。
When asking the server to get the current value of these parameters, this header can be sent in the GET-PARAMS method with the list of vendor-specific attribute names to get separated by a semicolon.
これらのパラメタの現行価値を得るようにサーバに頼むとき、セミコロンではぐれるようにベンダー特有の属性名のリストがあるGET-PARAMSメソッドでこのヘッダーを送ることができます。
7.4.8. Speech Marker
7.4.8. スピーチマーカー
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にイベントを生成するでしょう。 この分野SHOULDはSPEECH-MARKERイベントの一部であり、マーカータグ値を含むでしょう。
speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF
「スピーチマーカー=「スピーチマーカー」」:、」 1*アルファーCRLF
7.4.9. Speech Language
7.4.9. スピーチ言語
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.
それがスピーチデータで指定されないなら、このヘッダーフィールドはスピーチデータのデフォルト言語を指定します。 このヘッダーフィールドの値は値のためのRFC3066[16]に続くべきです。 これはSPEAK、SET-PARAMS、またはGET-PARAMS要求に起こるかもしれません。
speech-language = "Speech-Language" ":" 1*ALPHA CRLF
「スピーチ言語は「スピーチ言語」と等しい」:、」 1*アルファーCRLF
Shanmugham, et al. Informational [Page 27] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[27ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.4.10. Fetch Hint
7.4.10. ヒントをとって来てください。
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
「フェッチヒント=「フェッチヒント」」:、」 1*アルファーCRLF
7.4.11. Audio Fetch Hint
7.4.11. オーディオフェッチヒント
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
「オーディオフェッチヒント=「オーディオフェッチヒント」」:、」 1*アルファーCRLF
7.4.12. Fetch Timeout
7.4.12. タイムアウトをとって来てください。
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
「フェッチタイムアウトは「フェッチタイムアウト」と等しい」:、」 1*ケタCRLF
7.4.13. Failed URI
7.4.13. 失敗したURI
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にとって来るか、またはアクセスするためにシンセサイザを必要として、アクセスが失敗すると、メディアサーバSHOULDはメソッド応答で失敗したURIをこのヘッダーフィールドに提供します。
failed-uri = "Failed-URI" ":" Url CRLF
「失敗したuriは「失敗したURI」と等しい」:、」 Url CRLF
Shanmugham, et al. Informational [Page 28] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[28ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.4.14. Failed URI Cause
7.4.14. 失敗したURI原因
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にとって来るか、またはアクセスするためにシンセサイザを必要として、アクセスが失敗すると、メディアサーバSHOULDはこのヘッダーフィールドを通してURIの特定の、または、プロトコル特有の応答コードをメソッド応答に提供します。 この分野はそれの或るものが数値応答コードの代わりに応答ストリングを持っているかもしれないすべてのプロトコルに対応するためには英数字と定義されました。
failed-uri-cause = "Failed-URI-Cause" ":" 1*ALPHA CRLF
「失敗したuri原因は「失敗したURI原因」と等しい」:、」 1*アルファーCRLF
7.4.15. Speak Restart
7.4.15. 再開を話してください。
When a CONTROL jump backward request is issued to a currently speaking synthesizer resource and the jumps beyond the start of the speech, the current SPEAK request re-starts from the beginning of its speech data and the response to the CONTROL request would contain this header indicating a restart. This header MAY occur in the CONTROL response.
CONTROLジャンプであるときに、後方の要求はスピーチの始まりを超えて現在話すシンセサイザリソースとジャンプに出されます、そして、現在のSPEAK要求はスピーチデータの始まりから再開します、そして、CONTROL要求への応答は再開を示すこのヘッダーを含んでいるでしょう。 このヘッダーはCONTROL応答で起こるかもしれません。
speak-restart = "Speak-Restart" ":" boolean-value CRLF
「言葉再開=「言葉再開」」:、」 ブール値CRLF
7.4.16. Speak Length
7.4.16. 長さを話してください。
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".
このパラメタは話すためにスピーチの長さを制御するCONTROLメソッドで指定されるかもしれません、現在活発なSPEAK要求でポイントを話す電流に比例して。 「-」値はこの分野で不法です。 Tagユニットがある分野が指定されるなら、タグに達するまでメディアが話さなければならない、さもなければどれが一番になってもSPEAK要求が完成するその時です。 これは、スピーチデータで話すために長さを示すというSPEAK要求で指定されるかもしれなくて、SPEAK要求が始まるスピーチにおけるポイントに比例しています。 ユニットがサポートした異なったスピーチの長さはシンセサイザ実装に依存しています。 ユニットか操作をサポートしないなら、リソースSHOULDは「不法入国者かUnsupportedがパラメタのために評価する」404のステータスコードで応じます。
speak-length = "Speak-Length" ":" speech-length-value
CRLF
「言葉長さは「言葉長さ」と等しい」:、」 スピーチ長さの価値のCRLF
7.5. Synthesizer Message Body
7.5. シンセサイザメッセージ本体
A synthesizer message may contain additional information associated with the Method, Response, or Event in its message body.
シンセサイザメッセージはメッセージ本体でMethod、Response、またはEventに関連している追加情報を含むかもしれません。
Shanmugham, et al. Informational [Page 29] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[29ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.5.1. Synthesizer Speech Data
7.5.1. シンセサイザスピーチデータ
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's Speech Synthesis Markup Language[9]であるとサポートしなければならなくて、したがって、最小限でMIMEの種類がテキスト/平野とアプリケーション/統合+ssmlであるとサポートしなければなりません。
If the speech data needs to be specified by URI reference, the MIME type text/uri-list is used to specify the one or more URIs that will list what needs to be spoken. If a list of speech URIs is specified, speech data provided by each URI must be spoken in the order in which the URI are specified.
スピーチデータが、URI参照で指定される必要があるなら、MIMEの種類uriテキスト/リストは、話される必要があることを記載する1つ以上のURIを指定するのに使用されます。 スピーチURIのリストが指定されるなら、URIが指定されているオーダーで各URIによって提供されたスピーチデータを話さなければなりません。
If the data to be spoken consists of a mix of URI and inline speech data, the multipart/mixed MIME-type is used and embedded with the MIME-blocks for text/uri-list, application/synthesis+ssml or text/plain. The character set and encoding used in the speech data may be specified according to standard MIME-type definitions. The multi-part MIME-block can contain actual audio data in .wav or Sun audio format. This is used when the client has audio clips that it may have recorded, then stored in memory or a local device, and that it currently needs to play as part of the SPEAK request. The audio MIME-parts can be sent by the client as part of the multi-part MIME- block. This audio will be referenced in the speech markup data that will be another part in the multi-part MIME-block according to the multipart/mixed MIME-type specification.
話されるべきデータがURIとインラインスピーチデータのミックスから成るなら、複合の、または、混ぜられたMIMEの種類は、uriテキスト/リストのためのMIMEブロックで使用されて、埋め込まれます、アプリケーション/統合+ssmlかテキスト/明瞭です。 標準のMIMEの種類定義に従って、スピーチデータで使用される文字集合とコード化は指定されるかもしれません。 複合MIMEブロックは.wavの実際のオーディオデータかSunオーディオ形式を含むことができます。 クライアントがそれが現在メモリかローカル装置に記録して、次に保存したかもしれなくて、SPEAK要求の一部として使う必要があるオーディオクリップを持っているとき、これは使用されています。 クライアントは複合MIMEブロックの一部としてオーディオMIME部品を送ることができます。 このオーディオは複合の、または、複雑なMIMEの種類仕様に従った複合MIMEブロックで別の部分になるスピーチマーク付けデータで参照をつけられるでしょう。
Example 1:
Content-Type:text/uri-list
Content-Length:176
例1: コンテントタイプ: uri-リストテキスト/コンテンツの長さ: 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
例2: コンテントタイプ: ssmlアプリケーション/統合+コンテンツの長さ: 104
<?xml version="1.0"?>
<?xmlバージョン= 「1インチ?」>。
Shanmugham, et al. Informational [Page 30] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[30ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
あなたが4つの新しいメッセージ</文の><に判決を下させる<言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
Example 3:
Content-Type:multipart/mixed; boundary="--break"
例3: コンテントタイプ: 複合か混ぜられる。 「境界=」--壊れてください、」
--break
Content-Type:text/uri-list
Content-Length:176
--中断コンテントタイプ: uriテキスト/リストのContent-長さ: 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 Content長さ: 104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
--break
「<文の>、対象は音律が「>スキー旅行</音律></文の></パラグラフ></言葉の>--壊れます」であると= 」 -20%評定する<です。
Shanmugham, et al. Informational [Page 31] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[31ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.6. SET-PARAMS
7.6. セット-PARAMS
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のResponse状態を返さなければなりません。 いくつかの任意のパラメタを無視するのを選んだなら、それは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のResponse-状態で応じなければならなくて、応答に設定できなかったヘッダーフィールドを含まなければなりません。
Example:
C->S:SET-PARAMS 543256 MRCP/1.0
Voice-gender:female
Voice-category:adult
Voice-variant:3
例: C>S: セット-PARAMS543256MRCP/1.0声性: 女性の声カテゴリ: 大人の声異形: 3
S->C:MRCP/1.0 543256 200 COMPLETE
S>C: 200が完成するMRCP/1.0 543256
7.7. GET-PARAMS
7.7. PARAMSを手に入れます。
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メソッドはクライアントからサーバまで声の特性と音律のような現在のシンセサイザ文脈パラメタなどのためのシンセサイザリソースを尋ねます。 クライアントSHOULDはそれがサーバから1セットの空のパラメタヘッダーフィールドを記載することによって読みたがっているパラメタのリストを送ります。 特定のリストが指定されないなら、サーバSHOULDはベンダー特有のパラメタとそれらの現行価値を含むすべての「舗装用敷石-可能」パラメタを返します。 ベンダーによって、「舗装用敷石-可能」パラメタの数が大きいことができるようにワイルドカード使用は非常に徹底的である場合があります。 したがって、クライアントが頻繁にワイルドカードGET-PARAMS操作を使用しないのは、RECOMMENDEDです。
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: PARAMSを手に入れている543256MRCP/1.0声性: 声カテゴリ: 声異形: ベンダーの特定のパラメタ: com.mycorp.param1。 com.mycorp.param2
S->C:MRCP/1.0 543256 200 COMPLETE
Voice-gender:female
Voice-category:adult
Voice-variant:3
S>C: MRCP/1.0 543256 200の完全な声性: 女性の声カテゴリ: 大人の声異形: 3
Shanmugham, et al. Informational [Page 32] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[32ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
Vendor-Specific-Parameters:com.mycorp.param1="Company Name";
com.mycorp.param2="124324234@mycorp.com"
ベンダーの特定のパラメタ: com.mycorp.param1は「会社名」と等しいです。 com.mycorp.param2は" 124324234@mycorp.com "と等しいです。
7.8. SPEAK
7.8. 話してください。
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の分野が要求するヘッダーで指定されたもので続いて、したがって、その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要求が活発に処理されていると、リソースはIN-PROGRESSの成功ステータスコードと要求州と共に応じるでしょう。
If the resource is in the speaking or paused states (i.e., it is in the middle of processing a previous SPEAK request), the status returns success and a request-state of PENDING. This means that this SPEAK request is in queue and will be processed after the currently active SPEAK request is completed.
リソースが話しかポーズされた州にあるなら(すなわち、それは前のSPEAK要求を処理する中央にあります)、状態は成功とPENDINGの要求州を返します。 これは、このSPEAK要求が待ち行列中であることを意味して、現在活発なSPEAK要求が終了した後に処理されるでしょう。
For the synthesizer resource, this is the only request that can return a request-state of IN-PROGRESS or PENDING. When the text to be synthesized is complete, the resource will issue a SPEAK-COMPLETE event with the request-id of the SPEAK message and a request-state of COMPLETE.
シンセサイザリソースを求めて、これはIN-PROGRESSかPENDINGの要求州を返すことができる唯一の要求です。 統合されるべきテキストが完全であるときに、リソースはSPEAKメッセージの要求イドとCOMPLETEの要求州と共にSPEAK-COMPLETE出来事を発行するでしょう。
Example:
C->S:SPEAK 543257 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
例: C>S: 543257MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: ssmlアプリケーション/統合+コンテンツの長さ: 104を話してください。
Shanmugham, et al. Informational [Page 33] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[33ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543257 200
S->C:SPEAK-COMPLETE 543257 COMPLETE MRCP/1.0
Completion-Cause:000 normal
S>C: SPEAK-COMPLETE543257COMPLETE MRCP/1.0Completion-原因: 000標準
7.9. STOP
7.9. 停止
The STOP method from the client to the server tells the resource to stop speaking if it is speaking something.
クライアントからサーバまでのSTOP方法は、何かを話しているなら話すのを止めるようにリソースに言います。
The STOP request can be sent with an active-request-id-list header field to stop the zero or more specific SPEAK requests that may be in queue and return a response code of 200(Success). If no active- request-id-list header field is sent in the STOP request, it will terminate all outstanding SPEAK requests.
待ち行列中であるかもしれないゼロか、より特定のSPEAK要求を止めて、200(成功)の応答コードを返すためにアクティブな要求イドリストヘッダーフィールドと共にSTOP要求を送ることができます。 STOP要求でどんなアクティブな要求イドリストヘッダーフィールドも送らないと、それはすべての傑出しているSPEAK要求を終えるでしょう。
If a STOP request successfully terminated one or more PENDING or IN-PROGRESS SPEAK requests, then the response message body contains an active-request-id-list header field listing the SPEAK request-ids that were terminated. Otherwise, there will be no active-request- id-list header field in the response. No SPEAK-COMPLETE events will be sent for these terminated requests.
STOP要求が首尾よく1PENDINGかIN-PROGRESS SPEAK要求を終えたなら、応答メッセージ本体は終えられたSPEAK要求イドを記載するアクティブな要求イドリストヘッダーフィールドを含んでいます。 さもなければ、応答にはアクティブにイドリストを要求しているヘッダーフィールドが全くないでしょう。 これらの終えられた要求のためにSPEAK-COMPLETE出来事を全く送らないでしょう。
If a SPEAK request that was IN-PROGRESS and speaking was stopped, the next pending SPEAK request, if any, would become IN-PROGRESS and move to the speaking state.
IN-PROGRESSと話しであったSPEAK要求が止められるなら、もしあれば次の未定のSPEAK要求は、IN-PROGRESSになって、話す状態に動くでしょうに。
If a SPEAK request that was IN-PROGRESS and in the paused state was stopped, the next pending SPEAK request, if any, would become IN-PROGRESS and move to the paused state.
IN-PROGRESSとポーズされた状態にあったSPEAK要求が止められるなら、もしあれば次の未定のSPEAK要求は、IN-PROGRESSになって、ポーズされた状態に動くでしょうに。
Shanmugham, et al. Informational [Page 34] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[34ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
Example:
C->S:SPEAK 543258 MRCP/1.0
Content-Type:application/synthesis+ssml
Content-Length:104
例: C>S: 543258MRCP/1.0コンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543258 200
C->S:STOP 543259 200 MRCP/1.0
C>S: 停止543259 200MRCP/1.0
S->C:MRCP/1.0 543259 200 COMPLETE
Active-Request-Id-List:543258
S>C: MRCP/1.0 543259 200の完全なアクティブな要求イドリスト: 543258
7.10. BARGE-IN-OCCURRED
7.10. 起こるところではしけで運んでください。
The BARGE-IN-OCCURRED method is a mechanism for the client to communicate a barge-in-able event it detects to the speech resource.
BARGE IN OCCURRED方法はクライアントがそれがスピーチリソースに検出するできるところのはしけの出来事を伝えるメカニズムです。
This event is useful in two scenarios,
この出来事は2つのシナリオで役に立ちます。
1. The client has detected some events like DTMF digits or other
barge-in-able events and wants to communicate that to the
synthesizer.
1. クライアントは、DTMFケタや他のできるところのはしけの出来事のようにいくつかの出来事を検出して、それをシンセサイザに伝えたがっています。
2. The recognizer resource and the synthesizer resource are in
different servers. In which case the client MUST act as a Proxy
and receive event from the recognition resource, and then send a
BARGE-IN-OCCURRED method to the synthesizer. In such cases, the
BARGE-IN-OCCURRED method would also have a proxy-sync-id header
field received from the resource generating the original event.
2. 異なったサーバには認識器リソースとシンセサイザリソースがあります。 その場合、Proxyとして機能して、認識リソースから出来事を受けて、クライアントは、次に、BARGE IN OCCURRED方法をシンセサイザに送らなければなりません。 また、そのような場合、BARGE IN OCCURRED方法で、オリジナルの出来事を発生させるリソースからプロキシ同時性イドヘッダーフィールドを受け取るでしょう。
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
SPEAK要求が可能にされていた状態で中のはしけにおける獲物が活発であり、BARGE IN OCCURRED出来事が受け取られているなら、シンセサイザはストリーミングの出ているオーディオを止めるはずです。 また、それが現在のアクティブなものと、関係なさについて列に並ばせられたどんなスピーチ要求も終えるべきである、それら
Shanmugham, et al. Informational [Page 35] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[35ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
have barge-in enabled or not. If a barge-in-able prompt was playing and it was terminated, the response MUST contain the request-ids of all SPEAK requests that were terminated in its active-request-id- list. There will be no SPEAK-COMPLETE events generated for these requests.
中ではしけで運ぶのを可能にさせてください。 できるところのはしけのプロンプトがプレーしていて、それが終えられたなら、応答は活発な要求イドリストで終えられたすべてのSPEAK要求の要求イドを含まなければなりません。 これらの要求のために発生するSPEAK-COMPLETE出来事が全くないでしょう。
If the synthesizer and the recognizer are on the same server, they could be optimized for a quicker kill-on-barge-in response by having them interact directly based on a common RTSP session-id. In these cases, the client MUST still proxy the recognition event through a BARGE-IN-OCCURRED method, but the synthesizer resource may have already stopped and sent a SPEAK-COMPLETE event with a barge-in completion cause code. If there were no SPEAK requests terminated as a result of the BARGE-IN-OCCURRED method, the response would still be a 200 success, but MUST not contain an active-request-id-list header field.
シンセサイザと認識器が同じサーバにあるなら、それらは、より迅速な中のはしけにおける獲物応答のために直接一般的なRTSPセッションイドに基づいて相互作用させることによって、最適化されるかもしれません。 これらの場合では、クライアントが送らなければならなくて、それでも、しかし、BARGE IN OCCURRED方法、シンセサイザリソースを通した認識出来事がそうするプロキシは、中のはしけの完成原因コードと共に既に止まって、SPEAK-COMPLETE出来事を送りました。 BARGE IN OCCURRED方法の結果、終えられたSPEAK要求が全くなかったなら、応答は、まだ200成功でしょうが、アクティブな要求イドリストヘッダーフィールドを含んではいけません。
C->S:SPEAK 543258 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
C>S: 543258MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」タイプ=時間、「>午後3時45分の</言いたい事、-、>として」; 「</文の><文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543258 200
C->S:BARGE-IN-OCCURRED 543259 200 MRCP/1.0
Proxy-Sync-Id:987654321
C>S: 起こるところのはしけの543259、200MRCP/1.0プロキシ同時性イド: 987654321
S->C:MRCP/1.0 543259 200 COMPLETE
Active-Request-Id-List:543258
S>C: MRCP/1.0 543259 200の完全なアクティブな要求イドリスト: 543258
Shanmugham, et al. Informational [Page 36] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[36ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.11. PAUSE
7.11. くぎり
The PAUSE method from the client to the server tells the resource to pause speech, if it is speaking something. If a PAUSE method is issued on a session when a SPEAK is not active, the server SHOULD respond with a status of 402 or "Method not valid in this state". If a PAUSE method is issued on a session when a SPEAK is active and paused, the server SHOULD respond with a status of 200 or "Success". If a SPEAK request was active, the server MUST return an active- request-id-list header with the request-id of the SPEAK request that was paused.
何かを話しているなら、クライアントからサーバまでのPAUSE方法は、スピーチをポーズするようにリソースに言います。 SPEAKがアクティブでない、サーバSHOULDが402の状態で応じるセッションのときにPAUSE方法を発行するか、そして、「この状態で有効でない方法。」 セッションいつSPEAKがアクティブであり、ポーズされていて、サーバSHOULDが200の状態で応じるか、そして、「成功」でPAUSE方法を発行するなら。 SPEAK要求が活発であったなら、サーバはポーズされたSPEAK要求の要求イドがある活性要求イドリストヘッダーを返さなければなりません。
C->S:SPEAK 543258 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
C>S: 543258MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543258 200
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の完全なアクティブな要求イドリスト: 543258
7.12. RESUME
7.12. 履歴書
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
クライアントからサーバまでのRESUME方法は、話し続けるためにポーズされたシンセサイザリソースを言います。 SPEAKがアクティブでない、サーバSHOULDが402の状態で応じるセッションのときにRESUME方法を発行するか、そして、「この状態で有効でない方法。」 RESUME方法がSPEAKがアクティブであるセッションのときに発行されて、話しているなら(すなわち、止まりません)、サーバSHOULDは状態で応じます。
Shanmugham, et al. Informational [Page 37] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[37ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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
200か「成功」について。 SPEAK要求が活発であったなら、サーバは再開されたSPEAK要求の要求イドがあるアクティブな要求イドリストヘッダーを返さなければなりません。
Example:
C->S:SPEAK 543258 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
例: C>S: 543258MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543258 200
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の完全なアクティブな要求イドリスト: 543258
C->S:RESUME 543260 MRCP/1.0
C>S: 履歴書543260MRCP/1.0
S->C:MRCP/1.0 543260 200 COMPLETE
Active-Request-Id-List:543258
S>C: MRCP/1.0 543260 200の完全なアクティブな要求イドリスト: 543258
7.13. CONTROL
7.13. コントロール
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.
クライアントからサーバまでのCONTROL方法はそれが急いで話していることを変更するために話しているシンセサイザを言います。 この方法は、シンセサイザをそれが何であるかで話されながら前方か後方に跳ばせるのにおいて中古の変化スピーカー率とスピーカーパラメタですなど。 それはアクティブかIN-PROGRESS SPEAK要求に影響します。 シンセサイザリソースの実現と能力によって、それはこの操作かパラメタの1つ以上を許容するかもしれません。
Shanmugham, et al. Informational [Page 38] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[38ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
When a CONTROL to jump forward is issued and the operation goes beyond the end of the active SPEAK method's text, the request succeeds. A SPEAK-COMPLETE event follows the response to the CONTROL method. If there are more SPEAK requests in the queue, the synthesizer resource will continue to process the next SPEAK method. When a CONTROL to jump backwards is issued and the operation jumps to the beginning of the speech data of the active SPEAK request, the response to the CONTROL request contains the speak-restart header.
前方までジャンプするCONTROLが発行されて、操作がアクティブなSPEAK方法のテキストの終わりを越えるとき、要求は成功します。 SPEAK-COMPLETE出来事はCONTROL方法への応答に続いて起こります。 待ち行列における、より多くのSPEAK要求があると、シンセサイザリソースは、次のSPEAK方法を処理し続けるでしょう。 後方にジャンプするCONTROLが発行されて、操作がアクティブなSPEAKに関するデータが要求するスピーチの始まりまでジャンプするとき、CONTROL要求への応答は再開を話しているヘッダーを含んでいます。
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.
CONTROL方法を受け取ったとき、SPEAK要求が活発であったなら、サーバは活発であったSPEAK要求のRequest-イドがあるアクティブな要求イドリストヘッダーを返さなければなりません。
Example:
C->S:SPEAK 543258 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
例: C>S: 543258MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543258 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543258 200
C->S:CONTROL 543259 MRCP/1.0
Prosody-rate:fast
C>S: コントロール543259MRCP/1.0音律率: 断食してください。
S->C:MRCP/1.0 543259 200 COMPLETE
Active-Request-Id-List:543258
S>C: MRCP/1.0 543259 200の完全なアクティブな要求イドリスト: 543258
C->S:CONTROL 543260 MRCP/1.0
C>S: コントロール543260MRCP/1.0
Shanmugham, et al. Informational [Page 39] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[39ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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の完全なアクティブな要求イドリスト: 543258
7.14. SPEAK-COMPLETE
7.14. 言葉の完全です。
This is an Event message from the synthesizer resource to the client indicating that the SPEAK request was completed. The request-id header field WILL match the request-id of the SPEAK request that initiated the speech that just completed. The request-state field should be COMPLETE indicating that this is the last Event with that request-id, and that the request with that request-id is now complete. The completion-cause header field specifies the cause code pertaining to the status and reason of request completion such as the SPEAK completed normally or because of an error or kill-on-barge-in, etc.
シンセサイザリソースからSPEAK要求が終了したのを示すクライアントまでこれはEventメッセージです。 要求イドヘッダーフィールドはそれがただ終了したスピーチを開始したSPEAK要求の要求イドに合うでしょう。 要求州の分野はこれがその要求イドがある最後のEventであり、その要求イドによる要求が現在完全であることを示すCOMPLETEであるべきです。 完成原因ヘッダーフィールドは通常、終了するSPEAKなどか誤りか中のはしけにおける獲物による要求完成などの状態と理由に関係する原因コードを指定します。
Example:
C->S:SPEAK 543260 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
例: C>S: 543260MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」「>午後3時45分の</は-></として、>の判決を下すように言う」タイプ=時
<sentence>The subject is <prosody
rate="-20%">ski trip</prosody></sentence>
</paragraph>
</speak>
「<文の>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の></パラグラフ></言葉の>」です。
S->C:MRCP/1.0 543260 200 IN-PROGRESS
S>C: 進行中のMRCP/1.0 543260 200
S->C:SPEAK-COMPLETE 543260 COMPLETE MRCP/1.0
S>C: 言葉の完全な543260完全なMRCP/1.0
Completion-Cause:000 normal
完成原因: 000標準
Shanmugham, et al. Informational [Page 40] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[40ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
7.15. SPEECH-MARKER
7.15. スピーチマーカー
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.
これは現在処理しているスピーチ値上げでマーカータグを打つとシンセサイザリソースでクライアントに発生する出来事です。 ヘッダーの要求イド分野はスピーチを開始したSPEAK要求要求イドに合っています。 スピーチがまだ完全でなく、話されるために以上があるとき、要求州の分野はIN-PROGRESSであるべきです。 スピーチマーカーヘッダーフィールドでシンセサイザがスピーチ値上げどこで中であるかを説明して、打たれた生の言葉マーカータグを返します。
Example:
C->S:SPEAK 543261 MRCP/1.0
Voice-gender:neutral
Voice-category:teenager
Prosody-volume:medium
Content-Type:application/synthesis+ssml
Content-Length:104
例: C>S: 543261MRCP/1.0声性: 中立声カテゴリ: ティーンエイジャー音律ボリューム: 中型のコンテントタイプ: 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>
<mark name="here"/>
<sentence>The subject is
<prosody rate="-20%">ski trip</prosody>
</sentence>
<mark name="ANSWER"/>
</paragraph>
</speak>
<?xmlバージョン= 「1インチ?」あなたが4つの新しいメッセージ</文の><に判決を下させる><言葉の><パラグラフ><文の>、1番目が来ている>、たとえば、<、-、=をタイプしてください、「名前、「>ステファニーウィリアムズ</言いたい事、-、>であって<中断/>に到着する、たとえば、<、-、」タイプ=時間、「>午後3時45分の</言いたい事、-、>として」; 「</文の><マーク名=「ここ」という/><文>、対象は<音律レート=」 -20%「>スキー旅行</音律></文の><マーク名前="ANSWER"/></パラグラフ></言葉の>」です。
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: スピーチマーカーの543261の進行中のMRCP/1.0スピーチマーカー:、ここ
S->C:SPEECH-MARKER 543261 IN-PROGRESS MRCP/1.0
Speech-Marker:ANSWER
S>C: スピーチマーカーの543261の進行中のMRCP/1.0スピーチマーカー: 答えてください。
S->C:SPEAK-COMPLETE 543261 COMPLETE MRCP/1.0
Completion-Cause:000 normal
S>C: SPEAK-COMPLETE543261COMPLETE MRCP/1.0Completion-原因: 000標準
Shanmugham, et al. Informational [Page 41] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[41ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
8. Speech Recognizer Resource
8. スピーチ認識器リソース
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.
スピーチ認識器リソースは、入って来る声の流れを受けて、原文のフォームで話されたことに関する解釈をクライアントに提供できます。
8.1. Recognizer State Machine
8.1. 認識器州のマシン
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----------------|
州の州の州が認識したと認めて、怠けてください。| | | |---------認識します。---->|、-、--認識完全-->| | <、-、-、-、-、--停止------------| <、-、-、-、--認識します。-----------| | | | | | |-----------| | |--------| 結果を得ます。| | スピーチの始まり| |、-、-、-、-、-、-、-、-、--、>| |------------| |、-、-、-、-、-、--、>|、|、|、| |----------| | | 文法を定義します。| 認識スタートタイマ| | <、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、| |-------| | | | 停止| | | <、-、-、-、-、--、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--停止--------------------------| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--文法を定義します。----------------|
8.2. Recognizer Methods
8.2. 認識器方法
The recognizer supports the following methods.
recognizer-method = SET-PARAMS
/ GET-PARAMS
/ DEFINE-GRAMMAR
/ RECOGNIZE
/ GET-RESULT
/ RECOGNITION-START-TIMERS
/ STOP
認識器は以下の方法を支持します。認識器方法はSET-PARAMS/GET-PARAMS/DEFINE-GRAMMAR/RECOGNIZE/GET-RESULT/RECOGNITION-START-TIMERS/STOPと等しいです。
Shanmugham, et al. Informational [Page 42] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[42ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
8.3. Recognizer Events
8.3. 認識器出来事
The recognizer may generate the following events.
認識器は以下の出来事を発生させるかもしれません。
recognizer-event = START-OF-SPEECH
/ RECOGNITION-COMPLETE
認識器イベント=START-OF-SPEECH / RECOGNITION-COMPLETE
8.4. Recognizer Header Fields
8.4. 認識器ヘッダーフィールド
A recognizer message may contain header fields containing request options and information to augment the Method, Response, or Event message it is associated with.
認識器メッセージはそれが関連しているMethod、Response、またはEventメッセージを増大させる要求オプションと情報を含むヘッダーフィールドを含むかもしれません。
recognizer-header = confidence-threshold ; Section 8.4.1
/ sensitivity-level ; Section 8.4.2
/ speed-vs-accuracy ; Section 8.4.3
/ n-best-list-length ; Section 8.4.4
/ no-input-timeout ; Section 8.4.5
/ recognition-timeout ; Section 8.4.6
/ waveform-url ; Section 8.4.7
/ completion-cause ; Section 8.4.8
/ recognizer-context-block ; Section 8.4.9
/ recognizer-start-timers ; Section 8.4.10
/ vendor-specific ; Section 8.4.11
/ speech-complete-timeout ; Section 8.4.12
/ speech-incomplete-timeout; Section 8.4.13
/ dtmf-interdigit-timeout ; Section 8.4.14
/ dtmf-term-timeout ; Section 8.4.15
/ dtmf-term-char ; Section 8.4.16
/ fetch-timeout ; Section 8.4.17
/ failed-uri ; Section 8.4.18
/ failed-uri-cause ; Section 8.4.19
/ save-waveform ; Section 8.4.20
/ new-audio-channel ; Section 8.4.21
/ speech-language ; Section 8.4.22
認識器ヘッダーは信用敷居と等しいです。 セクション8.4.1/感度レベル。 セクション8.4速度.2/精度。 セクション8.4のn最も良いリストの.3/長さ。 セクション8.4入力.4/タイムアウトがありません。 セクション8.4認識.5/タイムアウト。 セクション8.4波形.6/url。 セクション8.4完成.7/原因。 セクション8.4.8/認識器文脈ブロック。 セクション8.4 認識器スタート.9/タイマ。 業者セクション8.4.10/特有。 セクション8.4のスピーチの完全な.11/タイムアウト。 セクション8.4のスピーチの不完全な.12/タイムアウト。 セクション8.4dtmf趾間部.13/タイムアウト。 セクション8.4dtmf用語.14/タイムアウト。 セクション8.4dtmf用語.15/炭。 セクション8.4フェッチ.16/タイムアウト。 セクション8.4の失敗した.17/uri。 セクション8.4の失敗したuri.18/原因。 波形をセクション8.4.19/節約します。 セクション8.4の新しい.20/音声チャンネル。 セクション8.4スピーチ.21/言語。 セクション8.4 .22
Parameter Support Methods/Events
パラメタサポート方法/イベント
confidence-threshold MANDATORY SET-PARAMS, RECOGNIZE
GET-RESULT
sensitivity-level Optional SET-PARAMS, GET-PARAMS,
RECOGNIZE
speed-vs-accuracy Optional SET-PARAMS, GET-PARAMS,
RECOGNIZE
n-best-list-length Optional SET-PARAMS, GET-PARAMS,
RECOGNIZE, GET-RESULT
no-input-timeout MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE
信用敷居MANDATORY SET-PARAMS、RECOGNIZE GET-RESULTはOptional SET-PARAMSを感度で平らにします、GET-PARAMS、RECOGNIZE速度精度Optional SET-PARAMS、GET-PARAMS、RECOGNIZE nの最も良いリストの長さのOptional SET-PARAMS、GET-PARAMS、RECOGNIZE、GET-RESULT入力タイムアウトがないMANDATORY SET-PARAMS、GET-PARAMS、RECOGNIZE
Shanmugham, et al. Informational [Page 43] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[43ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
recognition-timeout MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE
waveform-url MANDATORY RECOGNITION-COMPLETE
completion-cause MANDATORY DEFINE-GRAMMAR, RECOGNIZE,
RECOGNITON-COMPLETE
recognizer-context-block Optional SET-PARAMS, GET-PARAMS
recognizer-start-timers MANDATORY RECOGNIZE
vendor-specific MANDATORY SET-PARAMS, GET-PARAMS
speech-complete-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
speech-incomplete-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
dtmf-interdigit-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
dtmf-term-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
dtmf-term-char MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
fetch-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE, DEFINE-GRAMMAR
failed-uri MANDATORY DEFINE-GRAMMAR response,
RECOGNITION-COMPLETE
failed-uri-cause MANDATORY DEFINE-GRAMMAR response,
RECOGNITION-COMPLETE
save-waveform MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE
new-audio-channel MANDATORY RECOGNIZE
speech-language MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE, DEFINE-GRAMMAR
認識タイムアウトMANDATORY SET-PARAMS、GET-PARAMS、RECOGNIZE波形-url MANDATORY RECOGNITION-COMPLETE完成原因MANDATORY DEFINE-GRAMMAR、RECOGNIZE、RECOGNITON-COMPLETE認識器文脈ブロックOptional SET-PARAMS; GET-PARAMS認識器スタートタイマのMANDATORY RECOGNIZEのベンダー特有のMANDATORY SET-PARAMS、GET-PARAMSのスピーチの完全なタイムアウトMANDATORY SET-PARAMS、GET-PARAMS RECOGNIZEのスピーチの不完全なタイムアウトMANDATORY SET-PARAMS、GET-PARAMS RECOGNIZE dtmf趾間部タイムアウトMANDATORY SET-PARAMS; GET-PARAMS RECOGNIZE dtmf用語タイムアウトMANDATORY SET-PARAMS、GET-PARAMS RECOGNIZE dtmf用語炭のMANDATORY SET-PARAMS、GET-PARAMS RECOGNIZEフェッチタイムアウトMANDATORY SET-PARAMS、GET-PARAMS RECOGNIZE、DEFINE-GRAMMAR失敗したuri MANDATORY DEFINE-GRAMMAR応答、RECOGNITION-COMPLETE失敗したuri原因MANDATORY DEFINE-GRAMMAR応答、波形以外のRECOGNITION-COMPLETE MANDATORY SET-PARAMS、GET-PARAMS、RECOGNIZE新しい音声チャンネルMANDATORY RECOGNIZEスピーチ言語MANDATORY SET-PARAMS、GET-PARAMS、RECOGNIZEと、文法を定義します。
8.4.1. Confidence Threshold
8.4.1. 信用敷居
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からの整数です。 認識器が、すべての認識結果における信用が信用敷居以下であることを決定するなら、それは認識結果としてマッチを全く返してはいけません。 このヘッダーフィールドはRECOGNIZE、SET- PARAMS、またはGET-PARAMSに起こるかもしれません。この分野へのデフォルト値はプラットホーム特有です。
confidence-threshold = "Confidence-Threshold" ":" 1*DIGIT CRLF
「信用敷居=「信用敷居」」:、」 1*ケタCRLF
Shanmugham, et al. Informational [Page 44] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[44ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
8.4.2. Sensitivity Level
8.4.2. 感度レベル
To filter out background noise and not mistake it for speech, the recognizer may support a variable level of sound sensitivity. The sensitivity-level parameter allows the client to set this value on the recognizer. This header field MAY occur in RECOGNIZE, SET- PARAMS, or GET-PARAMS. A higher value for this field means higher sensitivity. The default value for this field is platform specific.
バックグラウンドノイズを無視して、それをスピーチに間違えないように、認識器は可変レベルの音の感度をサポートするかもしれません。 感度レベルパラメタで、クライアントは認識器の上にこの値を設定できます。 このヘッダーフィールドはRECOGNIZE、SET- PARAMS、またはGET-PARAMSに起こるかもしれません。この分野への、より高い値は、より高い感度を意味します。 この分野へのデフォルト値はプラットホーム特有です。
sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF
「感度レベルは「感度レベル」と等しい」:、」 1*ケタCRLF
8.4.3. Speed Vs Accuracy
8.4.3. 速度対精度
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.
認識器リソースの実装と能力によって、それはパフォーマンスかAccuracyに向かって調整可能であるかもしれません。 逆もまた同様により少ないメディアサーバあたりの呼び出しを意味して、より高い精度は、より多くの処理と、より高いCPU使用率を意味するかもしれません。 速度精度ヘッダーはリソースに関するこのパラメタを調整できます。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。この分野への、より高い値は、より高い速度を意味します。 この分野へのデフォルト値はプラットホーム特有です。
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 1*DIGIT CRLF
「速度精度は「速度精度」と等しい」:、」 1*ケタCRLF
8.4.4. N Best List Length
8.4.4. N最も良いリストの長さ
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つ以上の選択肢をそれに送るように認識リソースに頼むことができるでしょう。 すべての選択肢がまだ信用敷居を超えているに違いありません。 値1以上は、認識器が代替手段の要求された数を送るのを保証しません。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。この分野への最小値は1です。 この分野へのデフォルト値は1です。
n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF
「n最も良いリストの長さ=「N最も良いリストの長さ」」:、」 1*ケタCRLF
8.4.5. No Input Timeout
8.4.5. 入力タイムアウトがありません。
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,
認識が始められて、ある期間の間に検出されたスピーチが全くないとき、認識器は、RECOGNITION- COMPLETEイベントをクライアントに送って、認識操作を終えることができます。 入力タイムアウトがないヘッダーフィールドはこのタイムアウト値を設定できます。 値がミリセカンドであります。 このヘッダーフィールドはRECOGNIZEに起こるかもしれません。
Shanmugham, et al. Informational [Page 45] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[45ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
SET-PARAMS, or GET-PARAMS. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific.
SET-PARAMS、またはGET-PARAMSこの分野への値は0〜MAXTIMEOUTまで及びます。そこでは、MAXTIMEOUTがプラットホーム特有です。 この分野へのデフォルト値はプラットホーム特有です。
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
「入力タイムアウトは全く「入力タイムアウトがありません」と等しくない」:、」 1*ケタCRLF
8.4.6. Recognition Timeout
8.4.6. 認識タイムアウト
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.
認識が始められて、マッチが全くある期間の間ないとき、認識器は、RECOGNITION-COMPLETEイベントをクライアントに送って、認識操作を終えることができます。 認識タイムアウトパラメタ分野はこのタイムアウト値を設定します。 値がミリセカンドであります。 この分野への値は0〜MAXTIMEOUTまで及びます。そこでは、MAXTIMEOUTがプラットホーム特有です。 デフォルト値は10秒です。 このヘッダーフィールドはRECOGNIZE、SET-PARAMSまたはGET-PARAMSに起こるかもしれません。
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
「認識タイムアウトは「認識タイムアウト」と等しい」:、」 1*ケタCRLF
8.4.7. Waveform URL
8.4.7. 波形のURL
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.
波形を節約しているヘッダーフィールドが本当に設定されるなら、認識器は、認識の入って来るオーディオストリームをファイルの中に記録して、クライアントがそれにアクセスするように、URIを供給しなければなりません。 波形を節約しているヘッダーフィールドが本当に設定されたなら、このヘッダーはRECOGNITION-COMPLETEイベントで出席しているに違いありません。 録音からサーバを防ぐ何らかのエラー条件があったなら、ヘッダーのURL値はNULLでなければなりません。 さもなければ、URLはサーバでSHOULDを生成しました。サーバとそのすべての認識セッションの向こう側にグローバルにユニークであってください。 セッションまで利用可能なURL SHOULD BEを取りこわします。
waveform-url = "Waveform-URL" ":" Url CRLF
「波形-urlは「波形URL」と等しい」:、」 Url CRLF
8.4.8. Completion Cause
8.4.8. 完成原因
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.
このヘッダーフィールドは認識器リソースからクライアントに来るRECOGNITION-COMPLETEイベントの一部であるに違いありません。 これはRECOGNIZEメソッド完成の後ろに理由を示します。 DEFINE-GRAMMARとRECOGNIZE応答でこのヘッダーフィールドを送らなければなりません、失敗状態とCOMPLETE状態とともに帰るなら。
Cause-Code Cause-Name Description
原因コード原因名の記述
000 success RECOGNIZE completed with a match or
DEFINE-GRAMMAR succeeded in
downloading and compiling the
grammar
000 マッチで完成した成功RECOGNIZEかDEFINE-GRAMMARが文法をダウンロードして、コンパイルするのに成功しました。
Shanmugham, et al. Informational [Page 46] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[46ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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.
003認識タイムアウトRECOGNIZEが認識タイムアウト004グラム負荷失敗RECOGNIZEのためマッチなしで終了しなかった入力タイムアウトの全く失敗した当然の文法負荷失敗のためマッチなしで完成した002入力タイムアウトがないRECOGNIZEはマッチがないRECOGNIZEが完成した001にもかかわらず、どんなマッチにも見つけられませんでした。 005 グラムコンピュータの故障RECOGNIZEは文法編集失敗のため失敗しました。 006 RECOGNIZEが要求する誤りは早まって、認識器誤りのため終わりました。 007、スピーチ、早過ぎる、スピーチが初期過ぎたので、RECOGNIZE要求は終わりました。 008 スピーチが長過ぎたので、RECOGNIZEが要求するあまりに多くのスピーチタイムアウトが終わりました。 009 URIにアクセスするuri-失敗Failure。 言語サポートされないLanguageがサポートしなかった010。
8.4.9. Recognizer Context Block
8.4.9. 認識器文脈ブロック
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メソッドが値なしでこのヘッダーフィールドを含んでいるなら、それは認識器文脈ブロックを返す認識器への要求です。 そのようなメッセージへの応答はメッセージ実体として認識器文脈ブロックを含むかもしれません。 サーバが認識器文脈ブロックを返すなら、応答はこのヘッダーフィールドを含まなければなりません、そして、値はその実体の満足しているイドに合わなければなりません。
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メソッドがこのヘッダーフィールドを含んでいるなら、それは認識器文脈データを含むメッセージ実体、およびこのヘッダーフィールドに合っている満足しているイドを含まなければなりません。
This content-id should match the content-id that came with the context data during the GET-PARAMS operation.
この満足しているイドはGET-PARAMS操作の間に文脈データと共に来た満足しているイドに合うべきです。
recognizer-context-block = "Recognizer-Context-Block" ":"
1*ALPHA CRLF
「認識器文脈ブロックは「認識器文脈ブロック」と等しい」:、」 1*アルファーCRLF
Shanmugham, et al. Informational [Page 47] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[47ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
8.4.10. Recognition Start Timers
8.4.10. 認識スタートタイマ
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".
RECOGNIZE要求の一部としてこのパラメタを送るかもしれません。 誤ることの値は、まだ入力がないタイマを始動しているのではなく、認識を始めるように認識器に言います。 クライアントがRECOGNITION-START-TIMERS要求を認識器に送るまで、認識器はタイマを始動するはずがありません。 認識器とシンセサイザエンジンが同じセッションの一部でないときに、これはシナリオで役に立ちます。 中のはしけにおける獲物プロンプトがプレーされているとき、ここで、あなたは同時に中のはしけにおける獲物を検出して、実装することができるくらいアクティブであるというRECOGNIZE要求が欲しいです。 しかし、同時に、プロンプトが終わるまで、あなたは、認識器に入力がないタイマを始動して欲しくはありません。 デフォルト値は「本当です」。
recognizer-start-timers = "Recognizer-Start-Timers" ":"
boolean-value CRLF
「認識器スタートタイマは「認識器スタートタイマ」と等しい」:、」 ブール値CRLF
8.4.11. Vendor Specific Parameters
8.4.11. ベンダーの特定のパラメタ
This set of headers allows the client to set Vendor Specific parameters.
このセットのヘッダーはクライアントにVendor Specificパラメタを設定させます。
This header can be sent in the SET-PARAMS method and is used to set vendor-specific parameters on the server. The vendor-av-pair-name can be any vendor-specific field name and conforms to the XML vendor-specific attribute naming convention. The vendor-av-pair- value is the value to set the attribute to, and needs to be quoted.
このヘッダーは、SET-PARAMSメソッドで送ることができて、サーバに関するベンダー特有のパラメタを設定するのに使用されます。ベンダーav組名は、どんなベンダー特有のフィールド名であることができも、XMLのベンダー特有の属性命名規則に従います。 ベンダー-av組値は、属性にそうするように設定する値であり、引用される必要があります。
When asking the server to get the current value of these parameters, this header can be sent in the GET-PARAMS method with the list of vendor-specific attribute names to get separated by a semicolon. This header field MAY occur in SET-PARAMS or GET-PARAMS.
これらのパラメタの現行価値を得るようにサーバに頼むとき、セミコロンではぐれるようにベンダー特有の属性名のリストがあるGET-PARAMSメソッドでこのヘッダーを送ることができます。 このヘッダーフィールドはSET-PARAMSかGET-PARAMSに起こるかもしれません。
8.4.12. Speech Complete Timeout
8.4.12. スピーチの完全なタイムアウト
This header field specifies the length of silence required following user speech before the speech recognizer finalizes a result (either accepting it or throwing a nomatch event). The speech-complete- timeout value is used when the recognizer currently has a complete match of an active grammar, and specifies how long it should wait for more input before declaring a match. By contrast, the incomplete timeout is used when the speech is an incomplete match to an active grammar. The value is in milliseconds.
スピーチ認識器が結果を成立させる(それを受け入れるか、またはnomatchイベントを投げて)前にユーザスピーチに続いて、このヘッダーフィールドは必要である沈黙の長さを指定します。 認識器が、現在アクティブな文法の完全なマッチを持って、マッチを申告する前にそれがどれくらい長い間より多くの入力を待つべきであるかを指定するとき、スピーチ完全なタイムアウトの値は使用されています。 スピーチがアクティブな文法への不完全なマッチであるときに、対照的に、不完全なタイムアウトは使用されています。値がミリセカンドであります。
speech-complete-timeout = "Speech-Complete-Timeout" ":"
1*DIGIT CRLF
「スピーチの完全なタイムアウトは「スピーチの完全なタイムアウト」と等しい」:、」 1*ケタCRLF
Shanmugham, et al. Informational [Page 48] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[48ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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がプラットホーム特有です。 この分野へのデフォルト値はプラットホーム特有です。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。
8.4.13. Speech Incomplete Timeout
8.4.13. スピーチの不完全なタイムアウト
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
「スピーチの不完全なタイムアウトは「スピーチの不完全なタイムアウト」と等しい」:、」 1*ケタCRLF
The speech-incomplete-timeout also applies when the speech prior to the silence is a complete match of an active grammar, but where it is possible to speak further and still match the grammar. By contrast, the complete timeout is used when the speech is a complete match to an active grammar and no further words can be spoken.
また、沈黙の前のスピーチがアクティブな文法の完全なマッチですが、さらに話して、まだ文法を合わせているのが可能であるところでスピーチの不完全なタイムアウトは適用されます。スピーチがアクティブな文法への完全なマッチであり、さらなる言葉を全く話すことができないとき、対照的に、完全なタイムアウトは使用されています。
A long speech-incomplete-timeout value delays the result completion and, therefore, makes the computer's response slow. A short speech- incomplete-timeout may lead to an utterance being broken up inappropriately.
長いスピーチの不完全なタイムアウト値で、結果完成を遅らせて、したがって、コンピュータの応答は遅くなります。 短いスピーチ不完全なタイムアウトは不適当に終えられる発声に通じるかもしれません。
The speech-incomplete-timeout is usually longer than the speech- complete-timeout to allow users to pause mid-utterance (for example, to breathe). This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
通常、スピーチの不完全なタイムアウトは、ユーザが中間の発声(例えば呼吸する)をポーズするのを許容するためにスピーチの完全なタイムアウトより長いです。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。
8.4.14. DTMF Interdigit Timeout
8.4.14. DTMF趾間部タイムアウト
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秒です。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。
Shanmugham, et al. Informational [Page 49] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[49ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":"
1*DIGIT CRLF
「dtmf趾間部タイムアウトは「DTMF趾間部タイムアウト」と等しい」:、」 1*ケタCRLF
8.4.15. DTMF Term Timeout
8.4.15. DTMF用語タイムアウト
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入力を認識するとき使用する終わりタイムアウトを指定します。 値がミリセカンドであります。 この分野への値は0〜MAXTIMEOUTまで及びます。そこでは、MAXTIMEOUTがプラットホーム特有です。 デフォルト値は10秒です。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
「dtmf用語タイムアウトは「DTMF用語タイムアウト」と等しい」:、」 1*ケタCRLF
8.4.16. DTMF-Term-Char
8.4.16. DTMF用語炭
This header field specifies the terminating DTMF character for DTMF input recognition. The default value is NULL which is specified as an empty header field. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドはDTMF入力認識に終わっているDTMFキャラクタを指定します。 デフォルト値は空のヘッダーフィールドとして指定されるNULLです。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。
dtmf-term-char = "DTMF-Term-Char" ":" CHAR CRLF
「dtmf用語炭は「DTMF用語炭」と等しい」:、」 炭のCRLF
8.4.17. Fetch Timeout
8.4.17. タイムアウトをとって来てください。
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がプラットホーム特有です。 この分野へのデフォルト値はプラットホーム特有です。 このヘッダーフィールドはRECOGNIZE、SET-PARAMS、またはGET-PARAMSに起こるかもしれません。
8.4.18. Failed URI
8.4.18. 失敗したURI
When a recognizer method needs a recognizer to fetch or access a URI, and the access fails, the media server SHOULD provide the failed URI in this header field in the method response.
認識器メソッドがURIにとって来るか、またはアクセスするために認識器を必要として、アクセスが失敗すると、メディアサーバSHOULDはメソッド応答で失敗したURIをこのヘッダーフィールドに提供します。
8.4.19. Failed URI Cause
8.4.19. 失敗したURI原因
When a recognizer method needs a recognizer to fetch or access a URI, and the access fails, the media server SHOULD provide the URI- specific or protocol-specific response code through this header field in the method response. This field has been defined as alphanumeric to accommodate all protocols, some of which might have a response string instead of a numeric response code.
認識器メソッドがURIにとって来るか、またはアクセスするために認識器を必要として、アクセスが失敗すると、メディアサーバSHOULDはこのヘッダーフィールドを通してURIの特定の、または、プロトコル特有の応答コードをメソッド応答に提供します。 この分野はそれの或るものが数値応答コードの代わりに応答ストリングを持っているかもしれないすべてのプロトコルに対応するためには英数字と定義されました。
Shanmugham, et al. Informational [Page 50] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[50ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
8.4.20. Save Waveform
8.4.20. 波形を節約してください。
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".
このヘッダーフィールドで、クライアントは、認識されたオーディオストリームを節約しなければならないのを認識器に示すことができます。 認識器で、RECOGNITION-COMPLETEイベントにおける波形-uriヘッダーフィールドで返されたURIの形で次に、認識されたオーディオを記録して、それはクライアントにとって利用可能にならなければなりません。 ストリームを記録するのにおいて誤りがあったか、またはそうでなければ、オーディオクリップが利用可能でないなら、認識器は空の波形-uriヘッダーフィールドを返さなければなりません。 これのための値がさばくデフォルトは「誤っています」。
save-waveform = "Save-Waveform" ":" boolean-value CRLF
「セーブ波形は「波形」と等しい」:、」 ブール値CRLF
8.4.21. New Audio Channel
8.4.21. 新しいオーディオチャンネル
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.
このヘッダーフィールドは、RECOGNIZEメッセージで指定されるかもしれなくて、クライアントが、そのポイントから新しいオーディオソース、チャンネル、またはスピーカーからオーディオデータを追い出すとメディアサーバに言うのを許容します。 認識リソースが何か系列統計や情報を集めたなら、それは、それを捨てて、新たにこのRECOGNIZEに出発しなければなりません。 これはクライアントが複数の通話のためのメディアサーバとの開いている認識セッションを再利用したがっているかもしれない場合で助けます。
new-audio-channel = "New-Audio-Channel" ":" boolean-value CRLF
「新しい音声チャンネルは「新しい音声チャンネル」と等しい」:、」 ブール値CRLF
8.4.22. Speech Language
8.4.22. スピーチ言語
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.
このヘッダーフィールドはセッションか要求の中で認識文法データの言語を指定します、それがデータの中で指定されないなら。 このヘッダーフィールドの値は値のためのRFC3066[16]に続くべきです。 RECOGNIZE、SET-PARAMS、またはGET-PARAMSが、これがDEFINE-GRAMMARに起こるかもしれないよう要求します。
8.5. Recognizer Message Body
8.5. 認識器メッセージボディー
A recognizer message may carry additional data associated with the method, response, or event. The client may send the grammar to be recognized in DEFINE-GRAMMAR or RECOGNIZE requests. When the grammar is sent in the DEFINE-GRAMMAR method, the server should be able to download compile and optimize the grammar. The RECOGNIZE request MUST contain a list of grammars that need to be active during the recognition. The server resource may send the recognition results in the RECOGNITION-COMPLETE event or the GET-RESULT response. This data will be carried in the message body of the corresponding MRCP message.
認識器メッセージはメソッド、応答、またはイベントに関連している追加データを運ぶかもしれません。 クライアントは、DEFINE-GRAMMARかRECOGNIZE要求で認識されるために文法を送るかもしれません。 文法をコンパイルして、DEFINE-GRAMMARメソッド、サーバがダウンロードできるべきであるコネを文法に送るときには最適化してください。RECOGNIZE要求は認識の間、アクティブである必要がある文法のリストを含まなければなりません。 サーバリソースはRECOGNITION-COMPLETEイベントかGET-RESULT応答における認識結果を送るかもしれません。 このデータは対応するMRCPメッセージのメッセージ本体で運ばれるでしょう。
Shanmugham, et al. Informational [Page 51] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[51ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
8.5.1. Recognizer Grammar Data
8.5.1. 認識器文法データ
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).
クライアントからサーバまでの認識器文法データがインラインで提供するか、参照であることができます。 いずれにせよ、それらはMIME実体としてMRCP要求メッセージのメッセージ本体で運ばれます。 文法は、インラインを指定するか、または参照で認識プロセスで合うのに使用される文法を指定します、そして、このデータは仕様がW3C's XMLやABNFのようにフォーマットする標準の文法、またはSunのJava Speech Grammar Formatなどの1で指定されます。 すべてのメディアサーバが、W3C's XMLのベースの文法がマークアップ形式[11]である(+ MIMEの種類アプリケーション/文法xml)とサポートしなければなりません、そして、SHOULDは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.
文法がメッセージでインラインで指定されるとき、クライアントは満足しているヘッダーの一部として満足しているイドをその文法に提供しなければなりません。 サーバはセッションの持続時間のために関連している満足しているイドであるその文法を保存しなければなりません。 同じ満足しているイドで新しい文法を定義することによって、保存された文法を上書きできます。 特別番組を通して満足しているイドに関連した文法に参照をつけることができる、「セッション:」 URI体系。
Example:
session:help@root-level.store
例: セッション: help@root-level.store
If grammar data needs to be specified by external URI reference, the MIME-type text/uri-list is used to list the one or more URI that will specify the grammar data. All media servers MUST support the HTTP URI access mechanism.
文法データが、外部のURI参照で指定される必要があるなら、MIMEの種類uriテキスト/リストは、文法データを指定する1つ以上のURIを記載するのに使用されます。 すべてのメディアサーバが、HTTP URIがアクセス機構であるとサポートしなければなりません。
If the data to be defined consists of a mix of URI and inline grammar data, the multipart/mixed MIME-type is used and embedded with the MIME-blocks for text/uri-list, application/grammar or application/grammar+xml. The character set and encoding used in the grammar data may be specified according to standard MIME-type definitions.
定義されるべきデータがURIとインライン文法データのミックスから成るなら、複合の、または、混ぜられたMIMEの種類は、uriテキスト/リスト、アプリケーション/文法またはアプリケーション/文法+xmlのためのMIMEブロックで使用されて、埋め込まれます。 標準のMIMEの種類定義に従って、文法データで使用される文字集合とコード化は指定されるかもしれません。
When more than one grammar URI or inline grammar block is specified in a message body of the RECOGNIZE request, it is an active list of grammar alternatives to listen. The ordering of the list implies the precedence of the grammars, with the first grammar in the list having the highest precedence.
1つ以上の文法URIかインライン文法ブロック以上がRECOGNIZE要求のメッセージ本体で指定されるとき、それは聴く文法代替手段に関する現役軍人名簿です。 リストの注文は文法の先行を含意します、持っている中で先行最も高いリストにおける最初の文法で。
Example 1:
Content-Type:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
例1: コンテントタイプ: xmlの満足しているアプリケーション/文法+イド: request1@form-level.store コンテンツの長さ: 104
<?xml version="1.0"?>
<?xmlバージョン= 「1インチ?」>。
Shanmugham, et al. Informational [Page 52] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[52ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!--デフォルト文法言語は米国の英語です--><文法xml: lang=「アン米国」バージョンは「1インチの>」と等しいです。
<!-- 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>
<!--トークンへのただ一つの言語付属--><規則イド=、「はい、「><1、-><では、項目が: lang=をxmlする、「fr-カリフォルニア「>ouiの</品目><の品目xml: lang=」アン米国、「>はいの</品目></1、-></では、>を統治してください、」
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!--規則拡張へのただ一つの言語付属--><規則イド=、「要求、「>、私が<1と話しますように、-、xml: lang=、「fr-カリフォルニア、「><項目>ミシェルトランブレーの</品目><項目>アンドレロイの</品目></1、-></では、>を統治してください、」
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!--トークンへの複数の言語付属--><規則イド=「people1"><トークンレキシコン=」アン米国、fr-カリフォルニア「>ロバート</トークン></規則>」
<!-- 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>
<!--同等なただ一つの言語付属拡張--><規則イド=、「people2"><1、-><の品目xmlについて: langが」 アン米国と等しい、「>ロバートの</品目><の品目xml: langが等しい、「fr-カリフォルニア、「>ロバートの</品目></1、-></では、>を統治してください、」
</grammar>
</文法>。
Example 2:
Content-Type:text/uri-list
Content-Length:176
例2: コンテントタイプ: uri-リストテキスト/コンテンツの長さ: 176
session:help@root-level.store
http://www.cisco.com/Directory-Name-List.grxml
http://www.cisco.com/Department-List.grxml
http://www.cisco.com/TAC-Contact-List.grxml
session:menu1@menu-level.store
セッション: help@root-level.store ディレクトリ名前http://www.cisco.com/List.grxml http://www.cisco.com/Department-List.grxml http://www.cisco.com/TAC-Contact-List.grxml セッション: menu1@menu-level.store
Example 3:
Content-Type:multipart/mixed; boundary="--break"
例3: コンテントタイプ: 複合か混ぜられる。 「境界=」--壊れてください、」
Shanmugham, et al. Informational [Page 53] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[53ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
--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
--中断コンテントタイプ: uriテキスト/リストのContent-長さ: 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 Contentイド: request1@form-level.store のContent-長さ: 104
<?xml version="1.0"?>
<?xmlバージョン= 「1インチ?」>。
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" 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 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>
<!-- 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>
<!-- multiple language attachment to a token --> <rule id="people1"> <token lexicon="en-US,fr-CA"> Robert </token> </rule>
<!-- the equivalent single-language attachment expansion -->
<!-- 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>
<rule id="people2"> <one-of> <item xml:lang="en-US">Robert</item> <item xml:lang="fr-CA">Robert</item> </one-of> </rule>
Shanmugham, et al. Informational [Page 54] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 54] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
</grammar>
--break
</grammar> --break
8.5.2. Recognizer Result Data
8.5.2. Recognizer Result Data
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.
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.
Example 1:
Content-Type:application/x-nlsml
Content-Length:104
Example 1: Content-Type:application/x-nlsml Content-Length:104
<?xml version="1.0"?>
<result grammar="http://theYesNoGrammar">
<interpretation>
<instance>
<myApp:yes_no>
<response>yes</response>
</myApp:yes_no>
</instance>
<input>ok</input>
</interpretation>
</result>
<?xml version="1.0"?> <result grammar="http://theYesNoGrammar"> <interpretation> <instance> <myApp:yes_no> <response>yes</response> </myApp:yes_no> </instance> <input>ok</input> </interpretation> </result>
8.5.3. Recognizer Context Block
8.5.3. Recognizer Context Block
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.
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.
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
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
Shanmugham, et al. Informational [Page 55] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 55] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
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.
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.
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.
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.
8.6. SET-PARAMS
8.6. SET-PARAMS
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.
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.
Example:
C->S:SET-PARAMS 543256 MRCP/1.0
Sensitivity-Level:20
Recognition-Timeout:30
Confidence-Threshold:85
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 COMPLETE
8.7. GET-PARAMS
8.7. GET-PARAMS
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.
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.
Shanmugham, et al. Informational [Page 56] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 56] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Example:
C->S:GET-PARAMS 543256 MRCP/1.0
Sensitivity-Level:
Recognition-Timeout:
Confidence-threshold:
Example: C->S:GET-PARAMS 543256 MRCP/1.0 Sensitivity-Level: Recognition-Timeout: Confidence-threshold:
S->C:MRCP/1.0 543256 200 COMPLETE
Sensitivity-Level:20
Recognition-Timeout:30
Confidence-Threshold:85
S->C:MRCP/1.0 543256 200 COMPLETE Sensitivity-Level:20 Recognition-Timeout:30 Confidence-Threshold:85
8.8. DEFINE-GRAMMAR
8.8. DEFINE-GRAMMAR
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.
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 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 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.
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
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"?>
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" 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 tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule>
Shanmugham, et al. Informational [Page 57] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 57] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
<!-- 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>
<!-- 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 COMPLETE Completion-Cause:000 success
C->S:DEFINE-GRAMMAR 543258 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:helpgrammar@root-level.store
Content-Length:104
C->S:DEFINE-GRAMMAR 543258 MRCP/1.0 Content-Type:application/grammar+xml Content-Id:helpgrammar@root-level.store Content-Length:104
<?xml version="1.0"?>
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
<rule id="request"> I need help </rule>
</grammar>
</grammar>
S->C:MRCP/1.0 543258 200 COMPLETE
Completion-Cause:000 success
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"?>
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">
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
<rule id="request"> I need help </rule>
S->C:MRCP/1.0 543258 200 COMPLETE
S->C:MRCP/1.0 543258 200 COMPLETE
Shanmugham, et al. Informational [Page 58] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 58] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Completion-Cause:000 success
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
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"?>
<?xml version="1.0"?>
<grammar xml:lang="en">
<grammar xml:lang="en">
<import uri="session:politeness@form-level.store"
name="polite"/>
<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>
<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>
<ruleref import="polite#startPolite"/> <ruleref uri="#command"/> <ruleref import="polite#endPolite"/> </rule>
<rule id="command">
<ruleref uri="#action"/> <ruleref uri="#object"/>
</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="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 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>
Shanmugham, et al. Informational [Page 59] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 59] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
</rule>
</rule>
</grammar>
</grammar>
S->C:MRCP/1.0 543259 200 COMPLETE
Completion-Cause:000 success
S->C:MRCP/1.0 543259 200 COMPLETE Completion-Cause:000 success
C->S:RECOGNIZE 543260 MRCP/1.0
N-Best-List-Length:2
Content-Type:text/uri-list
Content-Length:176
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
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 IN-PROGRESS
S->C:START-OF-SPEECH 543260 IN-PROGRESS MRCP/1.0
S->C:START-OF-SPEECH 543260 IN-PROGRESS MRCP/1.0
S->C:RECOGNITION-COMPLETE 543260 COMPLETE MRCP/1.0
Completion-Cause:000 success
Waveform-URL:http://web.media.com/session123/audio.wav
Content-Type:applicationt/x-nlsml
Content-Length:276
S->C: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>
<?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>
8.9. RECOGNIZE
8.9. RECOGNIZE
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.
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.
Shanmugham, et al. Informational [Page 60] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 60] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
If the resource is in the recognition state, the RECOGNIZE request MUST respond with a failure status.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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"?>
<?xml version="1.0"?>
Shanmugham, et al. Informational [Page 61] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 61] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" 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 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>
<!-- 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 IN-PROGRESS
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0
S->C: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
Completion-Cause:000 success Waveform-URL:http://web.media.com/session123/audio.wav Content-Type:application/x-nlsml Content-Length:276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
<?xml version="1.0"?> <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>
Shanmugham, et al. Informational [Page 62] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 62] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
8.10. STOP
8.10. STOP
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).
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
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"?>
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" 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 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>
<!-- 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 IN-PROGRESS
C->S:STOP 543258 200 MRCP/1.0
C->S:STOP 543258 200 MRCP/1.0
Shanmugham, et al. Informational [Page 63] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 63] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
S->C:MRCP/1.0 543258 200 COMPLETE
Active-Request-Id-List:543257
S->C:MRCP/1.0 543258 200 COMPLETE Active-Request-Id-List:543257
8.11. GET-RESULT
8.11. GET-RESULT
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.
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.
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.
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.
Example:
C->S:GET-RESULT 543257 MRCP/1.0
Confidence-Threshold:90
Example: C->S:GET-RESULT 543257 MRCP/1.0 Confidence-Threshold:90
S->C:MRCP/1.0 543257 200 COMPLETE
Content-Type:application/x-nlsml
Content-Length:276
S->C:MRCP/1.0 543257 200 COMPLETE 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>
<?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>
</Person> </xf:instance> <input> may I speak to Andre Roy </input> </interpretation> </result>
8.12. START-OF-SPEECH
8.12. START-OF-SPEECH
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
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
Shanmugham, et al. Informational [Page 64] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 64] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
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.
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.
This event should be generated irrespective of whether the synthesizer and recognizer are in the same media server or not.
This event should be generated irrespective of whether the synthesizer and recognizer are in the same media server or not.
8.13. RECOGNITION-START-TIMERS
8.13. RECOGNITION-START-TIMERS
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 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.
8.14. RECOGNITON-COMPLETE
8.14. RECOGNITON-COMPLETE
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.
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.
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
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"?>
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
Shanmugham, et al. Informational [Page 65] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 65] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
<!-- 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 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>
<!-- 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 IN-PROGRESS
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0
Completion-Cause:000 success
Waveform-URL:http://web.media.com/session123/audio.wav
Content-Type:application/x-nlsml
Content-Length:276
S->C: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>
<?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>
Shanmugham, et al. Informational [Page 66] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 66] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
8.15. DTMF Detection
8.15. DTMF Detection
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.
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.
9. Future Study
9. Future Study
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.
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.
10. Security Considerations
10. Security Considerations
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 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.
11. RTSP-Based Examples
11. RTSP-Based Examples
The following is an example of a typical session of speech synthesis and recognition between a client and the server.
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.
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.
C->S:SETUP rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:2
Transport:RTP/AVP;unicast;client_port=46456-46457
Content-Type:application/sdp
C->S:SETUP rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:2 Transport:RTP/AVP;unicast;client_port=46456-46457 Content-Type:application/sdp
Shanmugham, et al. Informational [Page 67] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 67] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Content-Length:190
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
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
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
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.
Opening a recognizer resource. Uses the existing session ID and ports.
C->S:SETUP rtsp://media.server.com/media/recognizer RTSP/1.0
CSeq:3
Transport:RTP/AVP;unicast;client_port=46456-46457;
mode=record;ttl=127
Session:12345678
C->S:SETUP rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:3 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
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
Shanmugham, et al. Informational [Page 68] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 68] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
An ANNOUNCE message with the MRCP SPEAK request initiates speech.
An ANNOUNCE message with the MRCP SPEAK request initiates speech.
C->S:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:4
Session:12345678
Content-Type:application/mrcp
Content-Length:456
C->S: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
SPEAK 543257 MRCP/1.0 Kill-On-Barge-In:false Voice-gender:neutral Voice-category:teenager Prosody-volume:medium Content-Type:application/synthesis+ssml Content-Length:104
<?xml version="1.0"?>
<speak>
<paragraph>
<sentence>You have 4 new messages.</sentence>
<sentence>The first is from <say-as
type="name">Stephanie Williams</say-as> <mark
name="Stephanie"/>
and arrived at <break/>
<say-as type="time">3:45pm</say-as>.</sentence>
<?xml version="1.0"?> <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>
<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
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 IN-PROGRESS
The synthesizer hits the special marker in the message to be spoken and faithfully informs the client of the event.
The synthesizer hits the special marker in the message to be spoken and faithfully informs the client of the event.
S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0
CSeq:5
Session:12345678
S->C:ANNOUNCE rtsp://media.server.com/media/synthesizer RTSP/1.0 CSeq:5 Session:12345678
Shanmugham, et al. Informational [Page 69] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 69] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Content-Type:application/mrcp
Content-Length:123
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.
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
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 COMPLETE MRCP/1.0
C->S:RTSP/1.0 200 OK
CSeq:6
C->S:RTSP/1.0 200 OK CSeq:6
The recognizer is issued a request to listen for the customer choices.
The recognizer is issued a request to listen for the customer choices.
C->S:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0
CSeq:7
Session:12345678
C->S: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
RECOGNIZE 543258 MRCP/1.0 Content-Type:application/grammar+xml Content-Length:104
<?xml version="1.0"?>
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- 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>
<!-- 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>
Shanmugham, et al. Informational [Page 70] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 70] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
S->C:RTSP/1.0 200 OK
CSeq:7
Content-Type:application/mrcp
Content-Length:123
S->C:RTSP/1.0 200 OK CSeq:7 Content-Type:application/mrcp Content-Length:123
MRCP/1.0 543258 200 IN-PROGRESS
MRCP/1.0 543258 200 IN-PROGRESS
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).
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
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>
<?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
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 IN-PROGRESS
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.
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
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
Shanmugham, et al. Informational [Page 71] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 71] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
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.
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.
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.
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.
The completion-cause code differentiates if this is normal completion or a kill-on-barge-in interruption.
The completion-cause code differentiates if this is normal completion or a kill-on-barge-in interruption.
S->C:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0
CSeq:9
Session:12345678
Content-Type:application/mrcp
Content-Length:273
S->C: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
START-OF-SPEECH 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
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 COMPLETE MRCP/1.0 Completion-Cause:000 normal
C->S:RTSP/1.0 200 OK
CSeq:10
C->S:RTSP/1.0 200 OK CSeq:10
The recognition resource matched the spoken stream to a grammar and generated results. The result of the recognition is returned by the server as part of the RECOGNITION-COMPLETE event.
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
S->C:ANNOUNCE rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:11 Session:12345678 Content-Type:application/mrcp
Shanmugham, et al. Informational [Page 72] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 72] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Content-Length:733
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
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
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
<?xml version="1.0"?> <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
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.
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.
C->S:TEARDOWN rtsp://media.server.com/media/recognizer RTSP/1.0
CSeq:13
Session:12345678
C->S:TEARDOWN rtsp://media.server.com/media/recognizer RTSP/1.0 CSeq:13 Session:12345678
S->C:RTSP/1.0 200 OK
CSeq:13
S->C:RTSP/1.0 200 OK CSeq:13
Shanmugham, et al. Informational [Page 73] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 73] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
12. Informative References
12. Informative References
[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., and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC 2616, June 1999.
[2] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998
[2] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[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) Version 2.0", W3C Candidate Recommendation, March 2004.
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] World Wide Web Consortium, "Speech Synthesis Markup Language
(SSML) Version 1.0", W3C Candidate Recommendation, September
2004.
[9] World Wide Web Consortium, "Speech Synthesis Markup Language (SSML) Version 1.0", W3C Candidate Recommendation, September 2004.
[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 Consortium, "Natural Language Semantics Markup Language (NLSML) for the Speech Interface Framework", W3C Working Draft, 30 May 2001.
[11] World Wide Web Consortium, "Speech Recognition Grammar
Specification Version 1.0", W3C Candidate Recommendation, March
2004.
[11] World Wide Web Consortium, "Speech Recognition Grammar Specification Version 1.0", W3C Candidate Recommendation, March 2004.
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Shanmugham, et al. Informational [Page 74] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 74] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
[14] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[14] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[15] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[15] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[16] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
[16] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
Shanmugham, et al. Informational [Page 75] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 75] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Appendix A. ABNF Message Definitions
Appendix A. ABNF Message Definitions
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
CHAR = %x01-7F ; any 7-bit US-ASCII character,
; excluding NUL
CHAR = %x01-7F ; any 7-bit US-ASCII character, ; excluding NUL
CR = %x0D ; carriage return
CR = %x0D ; carriage return
CRLF = CR LF ; Internet standard newline
CRLF = CR LF ; Internet standard newline
DIGIT = %x30-39 ; 0-9
DIGIT = %x30-39 ; 0-9
DQUOTE = %x22 ; " (Double Quote)
DQUOTE = %x22 ; " (Double Quote)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09 ; horizontal tab
HTAB = %x09 ; horizontal tab
LF = %x0A ; linefeed
LF = %x0A ; linefeed
OCTET = %x00-FF ; 8 bits of data
OCTET = %x00-FF ; 8 bits of data
SP = %x20 ; space
SP = %x20 ; space
WSP = SP / HTAB ; white space
WSP = SP / HTAB ; white space
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep 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-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
UTF8-CONT = %x80-BF
param = *pchar
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
qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
Shanmugham, et al. Informational [Page 76] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 76] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
quoted-pair = "\" (%x00-09 / %x0B-0C
/ %x0E-7F)
quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
/ "+" / "$" / ","
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
unreserved = alphanum / mark
unreserved = alphanum / mark
char = unreserved / escaped /
":" / "@" / "&" / "=" / "+" / "$" / ","
char = unreserved / escaped / ":" / "@" / "&" / "=" / "+" / "$" / ","
alphanum = ALPHA / DIGIT
alphanum = ALPHA / DIGIT
escaped = "%" HEXDIG HEXDIG
escaped = "%" HEXDIG HEXDIG
absoluteURI = scheme ":" ( hier-part / opaque-part )
absoluteURI = scheme ":" ( hier-part / opaque-part )
relativeURI = ( net-path / abs-path / rel-path )
[ "?" query ]
relativeURI = ( net-path / abs-path / rel-path ) [ "?" query ]
hier-part = ( net-path / abs-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 / ";" / "@"
/ "&" / "=" / "+" / "$" / "," )
rel-segment = 1*( unreserved / escaped / ";" / "@" / "&" / "=" / "+" / "$" / "," )
opaque-part = uric-no-slash *uric
opaque-part = uric-no-slash *uric
uric = reserved / unreserved / escaped
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":"
/ "@" / "&" / "=" / "+" / "$" / ","
uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
segment = *pchar *( ";" param )
Shanmugham, et al. Informational [Page 77] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 77] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
reg-name = 1*( unreserved / escaped / "$" / "," / ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
query = *uric
userinfo = ( user ) [ ":" password ] "@"
userinfo = ( user ) [ ":" password ] "@"
user = 1*( unreserved / escaped
/ user-unreserved )
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";"
/ "?" / "/"
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
password = *( unreserved / escaped /
"&" / "=" / "+" / "$" / "," )
password = *( unreserved / escaped / "&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" )
alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::"
[ hexseq ]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
hex4 = 1*4HEXDIG
Shanmugham, et al. Informational [Page 78] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham, et al. Informational [Page 78] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
port = 1*DIGIT
port = 1*DIGIT
generic-message = start-line
message-header
CRLF
[ message-body ]
generic-message = start-line message-header CRLF [ message-body ]
message-body = *OCTET
message-body = *OCTET
start-line = request-line / status-line / event-line
スタート線イベント=要求線/状況表示行/線
request-line = method-name SP request-id SP
mrcp-version CRLF
要求線=方法名SP要求イドSP mrcp-バージョンCRLF
status-line = mrcp-version SP request-id SP
status-code SP request-state CRLF
状況表示行=mrcp-バージョンSP要求イドSPステータスコードSP要求州のCRLF
event-line = event-name SP request-id SP
request-state SP mrcp-version CRLF
イベント線=イベント名SP要求イドSP要求州SP mrcp-バージョンCRLF
message-header = 1*(generic-header / resource-header)
メッセージヘッダー=1*(リソース一般的なヘッダー/ヘッダー)
generic-header = active-request-id-list
/ proxy-sync-id
/ content-id
/ content-type
/ content-length
/ content-base
/ content-location
/ content-encoding
/ cache-control
/ logging-tag
; -- content-id is as defined in RFC 2392 and RFC 2046
内容をコード化しているか、コントロールをキャッシュする、登録している満足している満足している満足している満足している一般的なヘッダー=プロキシ同時性アクティブな要求イドリスト/イド/イド/タイプ/コンテンツの長さ/ベース/位置/タグ。 -- 満足しているイドがRFC2392とRFC2046で定義されるようにあります。
mrcp-version = "MRCP" "/" 1*DIGIT "." 1*DIGIT
「mrcpバージョン="MRCP"」/、」 1*ケタ、」、」 1*ケタ
request-id = 1*DIGIT
要求イド=1*DIGIT
status-code = 1*DIGIT
ステータスコードは1*DIGITと等しいです。
active-request-id-list = "Active-Request-Id-List" ":"
request-id *("," request-id) CRLF
「アクティブな要求イドリストは「アクティブな要求イドリスト」と等しい」:、」 要求イド*、(「」、要求イド) CRLF
proxy-sync-id = "Proxy-Sync-Id" ":" 1*ALPHA CRLF
「プロキシ同時性イド=「プロキシ同時性イド」」:、」 1*アルファーCRLF
content-length = "Content-Length" ":" 1*DIGIT CRLF
「コンテンツの長さは「コンテンツの長さ」と等しい」:、」 1*ケタCRLF
content-base = "Content-Base" ":" absoluteURI CRLF
「満足しているベースは「満足している基地」と等しい」:、」 absoluteURI CRLF
Shanmugham, et al. Informational [Page 79] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[79ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
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
「「内容コード化内容をコード化する=」」:、」 *「内容をコード化するWSP*、(*WSP、」、WSP) 」 内容をコード化する*WSP*CRLF
content-coding = token
内容をコード化する=象徴
content-location = "Content-Location" ":"
( absoluteURI / relativeURI ) CRLF
「満足している位置は「満足している位置」と等しい」:、」 (absoluteURI / relativeURI) CRLF
cache-control = "Cache-Control" ":"
*WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )
CRLF
「キャッシュ制御は「キャッシュ制御」と等しい」:、」 *「WSPキャッシュ指示*、(*WSP、」、WSP) 」 *WSPキャッシュ指示*CRLF
cache-directive = "max-age" "=" delta-seconds
/ "max-stale" "=" delta-seconds
/ "min-fresh" "=" delta-seconds
キャッシュ指示=「最大時代」「=」デルタ秒/「最大聞き古した」「=」デルタ秒/「生々しい分」「=」デルタ秒
logging-tag = "Logging-Tag" ":" 1*ALPHA CRLF
「伐採タグ=「伐採タグ」」:、」 1*アルファーCRLF
resource-header = recognizer-header
/ synthesizer-header
シンセサイザリソースヘッダー=認識器ヘッダー/ヘッダー
method-name = synthesizer-method
/ recognizer-method
認識器方法名=シンセサイザ方法/方法
event-name = synthesizer-event
/ recognizer-event
認識器イベント名=シンセサイザイベント/出来事
Shanmugham, et al. Informational [Page 80] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[80ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
request-state = "COMPLETE"
/ "IN-PROGRESS"
/ "PENDING"
「完全である」か「進行中」の、または、「未定」の要求州の=
synthesizer-method = "SET-PARAMS"
/ "GET-PARAMS"
/ "SPEAK"
/ "STOP"
/ "PAUSE"
/ "RESUME"
/ "BARGE-IN-OCCURRED"
/ "CONTROL"
シンセサイザ方法が「設定PARAMS」/と等しい、「」 /が「話す」か、または「止まる」というPARAMSを手に入れている/「くぎり」/「履歴書」/「起こるところのはしけ」/「コントロール」
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
言葉言葉失敗したuri失敗したフェッチオーディオフェッチフェッチスピーチスピーチ業者音律声完成スピーカー中のはしけにおけるシンセサイザヘッダー=ジャンプ目標/獲物/プロフィール/原因/パラメタ/パラメタ/詳細/マーカー/言語/ヒント/ヒント/タイムアウト/uri/原因/再開/長さ
recognizer-method = "SET-PARAMS"
/ "GET-PARAMS"
/ "DEFINE-GRAMMAR"
/ "RECOGNIZE"
/ "GET-RESULT"
/ "RECOGNITION-START-TIMERS"
/ "STOP"
認識器方法が「設定PARAMS」/と等しい、「PARAMSを手に入れる、」 /、「文法を定義する、」 /が/を「認識する」、「結果を得る、」 /「認識スタートタイマ」/「停止」
recognizer-event = "START-OF-SPEECH"
/ "RECOGNITION-COMPLETE"
認識器イベント=「スピーチの始まり」/「認識完全です」。
recognizer-header = confidence-threshold
/ sensitivity-level
/ speed-vs-accuracy
/ n-best-list-length
n最も良いリストの速度認識器ヘッダー=信用敷居/感度レベル/精度/長さ
Shanmugham, et al. Informational [Page 81] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[81ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
/ 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
スピーチ波形を節約している/新しい失敗したuri失敗したフェッチdtmf用語dtmf用語dtmf趾間部スピーチの不完全な業者認識器文脈ブロック/認識器スタート完成波形-url/原因/タイマ/特有の/スピーチ完全な認識/入力タイムアウトがない/タイムアウト/タイムアウト/タイムアウト/タイムアウト/タイムアウト/炭/タイムアウト/uri/原因/音声チャンネル/言語
jump-target = "Jump-Size" ":" speech-length-value CRLF
「ジャンプ目標=「ジャンプサイズ」」:、」 スピーチ長さの価値のCRLF
speech-length-value = numeric-speech-length
/ text-speech-length
スピーチ長さの価値はテキストスピーチの数値スピーチの長さ/長さと等しいです。
text-speech-length = 1*ALPHA SP "Tag"
テキストスピーチの長さ=1*ALPHA SP「タグ」
numeric-speech-length =("+" / "-") 1*DIGIT SP
numeric-speech-unit
数値スピーチの長さは1*ケタのSPの数値スピーチ単位と等しいです(「+」/「-」)。
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
数値スピーチ単位=「秒」/「言い表す」/「文」/「パラグラフ」
delta-seconds = 1*DIGIT
デルタ秒は1*DIGITと等しいです。
kill-on-barge-in = "Kill-On-Barge-In" ":" boolean-value CRLF
「中のはしけにおける獲物は「中ではしけの上で殺してください」と等しい」:、」 ブール値CRLF
boolean-value = "true" / "false"
「本当である」か「誤っていた」状態で=を論理演算子で評価してください。
speaker-profile = "Speaker-Profile" ":" absoluteURI CRLF
「スピーカープロフィールは「議長Profile」と等しい」:、」 absoluteURI CRLF
completion-cause = "Completion-Cause" ":" 1*DIGIT SP
1*ALPHA CRLF
「完成原因は「完成原因」と等しい」:、」 1*ケタSP1*アルファCRLF
voice-parameter = "Voice-" voice-param-name ":"
voice-param-value CRLF
「声パラメタは「声」 声のparam名」と等しいです」 声のparam価値のCRLF
Shanmugham, et al. Informational [Page 82] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[82ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
voice-param-name = 1*ALPHA
声のparam名の=1*アルファー
voice-param-value = 1*alphanum
声のparam価値は1*alphanumと等しいです。
prosody-parameter = "Prosody-" prosody-param-name ":"
prosody-param-value CRLF
「音律パラメタは「音律」 音律param名」と等しいです」 音律param価値のCRLF
prosody-param-name = 1*ALPHA
音律param名の=1*アルファー
prosody-param-value = 1*alphanum
音律param価値は1*alphanumと等しいです。
vendor-specific = "Vendor-Specific-Parameters" ":"
vendor-specific-av-pair
*[";" vendor-specific-av-pair] CRLF
「業者特有の=「業者の特定のパラメタ」」:、」 業者特定のav組*、[「」、;、業者特定のav組] CRLF
vendor-specific-av-pair = vendor-av-pair-name "="
vendor-av-pair-value
業者特定のav組=業者av組名「=」業者av組価値
vendor-av-pair-name = 1*ALPHA
業者av組名の=1*アルファー
vendor-av-pair-value = 1*alphanum
業者av組価値は1*alphanumと等しいです。
speech-marker = "Speech-Marker" ":" 1*ALPHA CRLF
「スピーチマーカー=「スピーチマーカー」」:、」 1*アルファーCRLF
speech-language = "Speech-Language" ":" 1*ALPHA CRLF
「スピーチ言語は「スピーチ言語」と等しい」:、」 1*アルファーCRLF
fetch-hint = "Fetch-Hint" ":" 1*ALPHA CRLF
「フェッチヒント=「フェッチヒント」」:、」 1*アルファーCRLF
audio-fetch-hint = "Audio-Fetch-Hint" ":" 1*ALPHA CRLF
「オーディオフェッチヒント=「オーディオフェッチヒント」」:、」 1*アルファーCRLF
fetch-timeout = "Fetch-Timeout" ":" 1*DIGIT CRLF
「フェッチタイムアウトは「フェッチタイムアウト」と等しい」:、」 1*ケタCRLF
failed-uri = "Failed-URI" ":" absoluteURI CRLF
「失敗したuriは「失敗したURI」と等しい」:、」 absoluteURI CRLF
failed-uri-cause = "Failed-URI-Cause" ":" 1*ALPHA CRLF
「失敗したuri原因は「失敗したURI原因」と等しい」:、」 1*アルファーCRLF
speak-restart = "Speak-Restart" ":" boolean-value CRLF
「言葉再開=「言葉再開」」:、」 ブール値CRLF
speak-length = "Speak-Length" ":" speech-length-value
CRLF
confidence-threshold = "Confidence-Threshold" ":"
1*DIGIT CRLF
「言葉長さは「言葉長さ」と等しい」:、」 「スピーチ長さの価値CRLF信用敷居=「信用敷居」」:、」 1*ケタCRLF
sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF
「感度レベルは「感度レベル」と等しい」:、」 1*ケタCRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 1*DIGIT CRLF
「速度精度は「速度精度」と等しい」:、」 1*ケタCRLF
n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF
「n最も良いリストの長さ=「N最も良いリストの長さ」」:、」 1*ケタCRLF
Shanmugham, et al. Informational [Page 83] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[83ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
「入力タイムアウトは全く「入力タイムアウトがありません」と等しくない」:、」 1*ケタCRLF
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
「認識タイムアウトは「認識タイムアウト」と等しい」:、」 1*ケタCRLF
waveform-url = "Waveform-URL" ":" absoluteURI CRLF
「波形-urlは「波形URL」と等しい」:、」 absoluteURI CRLF
recognizer-context-block = "Recognizer-Context-Block" ":"
1*ALPHA CRLF
「認識器文脈ブロックは「認識器文脈ブロック」と等しい」:、」 1*アルファーCRLF
recognizer-start-timers = "Recognizer-Start-Timers" ":"
boolean-value CRLF
「認識器スタートタイマは「認識器スタートタイマ」と等しい」:、」 ブール値CRLF
speech-complete-timeout = "Speech-Complete-Timeout" ":"
1*DIGIT CRLF
「スピーチの完全なタイムアウトは「スピーチの完全なタイムアウト」と等しい」:、」 1*ケタCRLF
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":"
1*DIGIT CRLF
「スピーチの不完全なタイムアウトは「スピーチの不完全なタイムアウト」と等しい」:、」 1*ケタCRLF
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":"
1*DIGIT CRLF
「dtmf趾間部タイムアウトは「DTMF趾間部タイムアウト」と等しい」:、」 1*ケタCRLF
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
「dtmf用語タイムアウトは「DTMF用語タイムアウト」と等しい」:、」 1*ケタCRLF
dtmf-term-char = "DTMF-Term-Char" ":" CHAR CRLF
「dtmf用語炭は「DTMF用語炭」と等しい」:、」 炭のCRLF
save-waveform = "Save-Waveform" ":" boolean-value CRLF
「セーブ波形は「波形」と等しい」:、」 ブール値CRLF
new-audio-channel = "New-Audio-Channel" ":"
boolean-value CRLF
「新しい音声チャンネルは「新しい音声チャンネル」と等しい」:、」 ブール値CRLF
Appendix B. Acknowledgements
付録B.承認
Andre Gillet (Nuance Communications) Andrew Hunt (SpeechWorks) Aaron Kneiss (SpeechWorks) Kristian Finlator (SpeechWorks) Martin Dragomirecky (Cisco Systems, Inc.) Pierre Forgues (Nuance Communications) Suresh Kaliannan (Cisco Systems, Inc.) Corey Stohs (Cisco Systems, Inc.) Dan Burnett (Nuance Communications)
アンドレ・ジレ(ニュアンスコミュニケーション)アンドリューHunt(SpeechWorks)アーロンKneiss(SpeechWorks)クリスチャンFinlator(SpeechWorks)マーチンDragomirecky(シスコシステムズInc.) ピアーForgues(ニュアンスコミュニケーション)Suresh Kaliannan(シスコシステムズInc.) コーリーStohs(シスコシステムズInc.) ダン・バーネット(ニュアンスコミュニケーション)
Shanmugham, et al. Informational [Page 84] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[84ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
Authors' Addresses
作者のアドレス
Saravanan Shanmugham Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134
Saravanan ShanmughamシスコシステムズInc.170W.タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: sarvi@cisco.com
メール: sarvi@cisco.com
Peter Monaco Nuasis Corporation 303 Bryant St. Mountain View, CA 94041
マウンテンビュー、ピーターモナコNuasis社303のブライアント通りカリフォルニア 94041
EMail: peter.monaco@nuasis.com
メール: peter.monaco@nuasis.com
Brian Eberman Speechworks, Inc. 695 Atlantic Avenue Boston, MA 02111
ブライアンEberman Speechworks Inc.695大西洋Avenueボストン、MA 02111
EMail: brian.eberman@speechworks.com
メール: brian.eberman@speechworks.com
Shanmugham, et al. Informational [Page 85] RFC 4463 MRCP by Cisco, Nuance, and Speechworks April 2006
Shanmugham、他 シスコによる情報[85ページ]のRFC4463MRCP、ニュアンス、およびSpeechworks2006年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Shanmugham, et al. Informational [Page 86]
Shanmugham、他 情報[86ページ]
一覧
スポンサーリンク
