[要約] RFC 6787は、MRCPv2の仕様を定義しており、音声認識や音声合成などのメディアリソースの制御を目的としています。MRCPv2は、クライアントとサーバー間の通信プロトコルとして使用され、音声アプリケーションの開発や統合を容易にします。
Internet Engineering Task Force (IETF) D. Burnett
Request for Comments: 6787 Voxeo
Category: Standards Track S. Shanmugham
ISSN: 2070-1721 Cisco Systems, Inc.
November 2012
Media Resource Control Protocol Version 2 (MRCPv2)
メディアリソースコントロールプロトコルバージョン2（MRCPv2）
Abstract
概要
The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server.
メディアリソースコントロールプロトコルバージョン2（MRCPv2）を使用すると、クライアントホストは、ネットワーク上のサーバーにある音声合成装置、認識装置、検証装置、識別子などのメディアサービスリソースを制御できます。 MRCPv2は「スタンドアロン」プロトコルではありません。MRCPv2クライアントとサーバーを調整し、それらの間のセッションを管理するために、Session Initiation Protocol（SIP）などの他のプロトコルに依存し、説明するためにSession Description Protocol（SDP）を使用します。 、発見、および交換機能。また、SIPおよびSDPに依存して、メディアソースまたはシンクとメディアサーバー間のメディアセッションと関連パラメーターを確立します。これが完了すると、MRCPv2交換は上記で確立された制御セッション上で動作し、クライアントが音声リソースサーバー上のメディア処理リソースを制御できるようになります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6787.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6787で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 9
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 10
2.2. State-Machine Diagrams . . . . . . . . . . . . . . . . . 10
2.3. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 11
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. MRCPv2 Media Resource Types . . . . . . . . . . . . . . 12
3.2. Server and Resource Addressing . . . . . . . . . . . . . 14
4. MRCPv2 Basics . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Connecting to the Server . . . . . . . . . . . . . . . . 14
4.2. Managing Resource Control Channels . . . . . . . . . . . 14
4.3. SIP Session Example . . . . . . . . . . . . . . . . . . 17
4.4. Media Streams and RTP Ports . . . . . . . . . . . . . . 22
4.5. MRCPv2 Message Transport . . . . . . . . . . . . . . . . 24
4.6. MRCPv2 Session Termination . . . . . . . . . . . . . . . 24
5. MRCPv2 Specification . . . . . . . . . . . . . . . . . . . . 24
5.1. Common Protocol Elements . . . . . . . . . . . . . . . . 25
5.2. Request . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . 30
5.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. MRCPv2 Generic Methods, Headers, and Result Structure . . . . 32
6.1. Generic Methods . . . . . . . . . . . . . . . . . . . . 32
6.1.1. SET-PARAMS . . . . . . . . . . . . . . . . . . . . . 32
6.1.2. GET-PARAMS . . . . . . . . . . . . . . . . . . . . . 33
6.2. Generic Message Headers . . . . . . . . . . . . . . . . 34
6.2.1. Channel-Identifier . . . . . . . . . . . . . . . . . 35
6.2.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.3. Active-Request-Id-List . . . . . . . . . . . . . . . 36
6.2.4. Proxy-Sync-Id . . . . . . . . . . . . . . . . . . . 36
6.2.5. Accept-Charset . . . . . . . . . . . . . . . . . . . 37
6.2.6. Content-Type . . . . . . . . . . . . . . . . . . . . 37
6.2.7. Content-ID . . . . . . . . . . . . . . . . . . . . . 38
6.2.8. Content-Base . . . . . . . . . . . . . . . . . . . . 38
6.2.9. Content-Encoding . . . . . . . . . . . . . . . . . . 38
6.2.10. Content-Location . . . . . . . . . . . . . . . . . . 39
6.2.11. Content-Length . . . . . . . . . . . . . . . . . . . 39
6.2.12. Fetch Timeout . . . . . . . . . . . . . . . . . . . 39
6.2.13. Cache-Control . . . . . . . . . . . . . . . . . . . 40
6.2.14. Logging-Tag . . . . . . . . . . . . . . . . . . . . 41
6.2.15. Set-Cookie . . . . . . . . . . . . . . . . . . . . . 42
6.2.16. Vendor-Specific Parameters . . . . . . . . . . . . . 44
6.3. Generic Result Structure . . . . . . . . . . . . . . . . 44
6.3.1. Natural Language Semantics Markup Language . . . . . 45
7. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 46
8. Speech Synthesizer Resource . . . . . . . . . . . . . . . . . 47
8.1. Synthesizer State Machine . . . . . . . . . . . . . . . 48
8.2. Synthesizer Methods . . . . . . . . . . . . . . . . . . 48
8.3. Synthesizer Events . . . . . . . . . . . . . . . . . . . 49
8.4. Synthesizer Header Fields . . . . . . . . . . . . . . . 49
8.4.1. Jump-Size . . . . . . . . . . . . . . . . . . . . . 49
8.4.2. Kill-On-Barge-In . . . . . . . . . . . . . . . . . . 50
8.4.3. Speaker-Profile . . . . . . . . . . . . . . . . . . 51
8.4.4. Completion-Cause . . . . . . . . . . . . . . . . . . 51
8.4.5. Completion-Reason . . . . . . . . . . . . . . . . . 52
8.4.6. Voice-Parameter . . . . . . . . . . . . . . . . . . 52
8.4.7. Prosody-Parameters . . . . . . . . . . . . . . . . . 53
8.4.8. Speech-Marker . . . . . . . . . . . . . . . . . . . 53
8.4.9. Speech-Language . . . . . . . . . . . . . . . . . . 54
8.4.10. Fetch-Hint . . . . . . . . . . . . . . . . . . . . . 54
8.4.11. Audio-Fetch-Hint . . . . . . . . . . . . . . . . . . 55
8.4.12. Failed-URI . . . . . . . . . . . . . . . . . . . . . 55
8.4.13. Failed-URI-Cause . . . . . . . . . . . . . . . . . . 55
8.4.14. Speak-Restart . . . . . . . . . . . . . . . . . . . 56
8.4.15. Speak-Length . . . . . . . . . . . . . . . . . . . . 56
8.4.16. Load-Lexicon . . . . . . . . . . . . . . . . . . . . 57
8.4.17. Lexicon-Search-Order . . . . . . . . . . . . . . . . 57
8.5. Synthesizer Message Body . . . . . . . . . . . . . . . . 57
8.5.1. Synthesizer Speech Data . . . . . . . . . . . . . . 57
8.5.2. Lexicon Data . . . . . . . . . . . . . . . . . . . . 59
8.6. SPEAK Method . . . . . . . . . . . . . . . . . . . . . . 60
8.7. STOP . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.8. BARGE-IN-OCCURRED . . . . . . . . . . . . . . . . . . . 63
8.9. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.10. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.11. CONTROL . . . . . . . . . . . . . . . . . . . . . . . . 67
8.12. SPEAK-COMPLETE . . . . . . . . . . . . . . . . . . . . . 69
8.13. SPEECH-MARKER . . . . . . . . . . . . . . . . . . . . . 70
8.14. DEFINE-LEXICON . . . . . . . . . . . . . . . . . . . . . 71
9. Speech Recognizer Resource . . . . . . . . . . . . . . . . . 72
9.1. Recognizer State Machine . . . . . . . . . . . . . . . . 74
9.2. Recognizer Methods . . . . . . . . . . . . . . . . . . . 74
9.3. Recognizer Events . . . . . . . . . . . . . . . . . . . 75
9.4. Recognizer Header Fields . . . . . . . . . . . . . . . . 75
9.4.1. Confidence-Threshold . . . . . . . . . . . . . . . . 77
9.4.2. Sensitivity-Level . . . . . . . . . . . . . . . . . 77
9.4.3. Speed-Vs-Accuracy . . . . . . . . . . . . . . . . . 77
9.4.4. N-Best-List-Length . . . . . . . . . . . . . . . . . 78
9.4.5. Input-Type . . . . . . . . . . . . . . . . . . . . . 78
9.4.6. No-Input-Timeout . . . . . . . . . . . . . . . . . . 78
9.4.7. Recognition-Timeout . . . . . . . . . . . . . . . . 79
9.4.8. Waveform-URI . . . . . . . . . . . . . . . . . . . . 79
9.4.9. Media-Type . . . . . . . . . . . . . . . . . . . . . 80
9.4.10. Input-Waveform-URI . . . . . . . . . . . . . . . . . 80
9.4.11. Completion-Cause . . . . . . . . . . . . . . . . . . 80
9.4.12. Completion-Reason . . . . . . . . . . . . . . . . . 83
9.4.13. Recognizer-Context-Block . . . . . . . . . . . . . . 83
9.4.14. Start-Input-Timers . . . . . . . . . . . . . . . . . 83
9.4.15. Speech-Complete-Timeout . . . . . . . . . . . . . . 84
9.4.16. Speech-Incomplete-Timeout . . . . . . . . . . . . . 84
9.4.17. DTMF-Interdigit-Timeout . . . . . . . . . . . . . . 85
9.4.18. DTMF-Term-Timeout . . . . . . . . . . . . . . . . . 85
9.4.19. DTMF-Term-Char . . . . . . . . . . . . . . . . . . . 85
9.4.20. Failed-URI . . . . . . . . . . . . . . . . . . . . . 86
9.4.21. Failed-URI-Cause . . . . . . . . . . . . . . . . . . 86
9.4.22. Save-Waveform . . . . . . . . . . . . . . . . . . . 86
9.4.23. New-Audio-Channel . . . . . . . . . . . . . . . . . 86
9.4.24. Speech-Language . . . . . . . . . . . . . . . . . . 87
9.4.25. Ver-Buffer-Utterance . . . . . . . . . . . . . . . . 87
9.4.26. Recognition-Mode . . . . . . . . . . . . . . . . . . 87
9.4.27. Cancel-If-Queue . . . . . . . . . . . . . . . . . . 88
9.4.28. Hotword-Max-Duration . . . . . . . . . . . . . . . . 88
9.4.29. Hotword-Min-Duration . . . . . . . . . . . . . . . . 88
9.4.30. Interpret-Text . . . . . . . . . . . . . . . . . . . 89
9.4.31. DTMF-Buffer-Time . . . . . . . . . . . . . . . . . . 89
9.4.32. Clear-DTMF-Buffer . . . . . . . . . . . . . . . . . 89
9.4.33. Early-No-Match . . . . . . . . . . . . . . . . . . . 90
9.4.34. Num-Min-Consistent-Pronunciations . . . . . . . . . 90
9.4.35. Consistency-Threshold . . . . . . . . . . . . . . . 90
9.4.36. Clash-Threshold . . . . . . . . . . . . . . . . . . 90
9.4.37. Personal-Grammar-URI . . . . . . . . . . . . . . . . 91
9.4.38. Enroll-Utterance . . . . . . . . . . . . . . . . . . 91
9.4.39. Phrase-Id . . . . . . . . . . . . . . . . . . . . . 91
9.4.40. Phrase-NL . . . . . . . . . . . . . . . . . . . . . 92
9.4.41. Weight . . . . . . . . . . . . . . . . . . . . . . . 92
9.4.42. Save-Best-Waveform . . . . . . . . . . . . . . . . . 92
9.4.43. New-Phrase-Id . . . . . . . . . . . . . . . . . . . 93
9.4.44. Confusable-Phrases-URI . . . . . . . . . . . . . . . 93
9.4.45. Abort-Phrase-Enrollment . . . . . . . . . . . . . . 93
9.5. Recognizer Message Body . . . . . . . . . . . . . . . . 93
9.5.1. Recognizer Grammar Data . . . . . . . . . . . . . . 93
9.5.2. Recognizer Result Data . . . . . . . . . . . . . . . 97
9.5.3. Enrollment Result Data . . . . . . . . . . . . . . . 98
9.5.4. Recognizer Context Block . . . . . . . . . . . . . . 98
9.6. Recognizer Results . . . . . . . . . . . . . . . . . . . 99
9.6.1. Markup Functions . . . . . . . . . . . . . . . . . . 99
9.6.2. Overview of Recognizer Result Elements and Their
Relationships . . . . . . . . . . . . . . . . . . . 100
9.6.3. Elements and Attributes . . . . . . . . . . . . . . 101
9.7. Enrollment Results . . . . . . . . . . . . . . . . . . . 106
9.7.1. <num-clashes> Element . . . . . . . . . . . . . . . 106
9.7.2. <num-good-repetitions> Element . . . . . . . . . . . 106
9.7.3. <num-repetitions-still-needed> Element . . . . . . . 107
9.7.4. <consistency-status> Element . . . . . . . . . . . . 107
9.7.5. <clash-phrase-ids> Element . . . . . . . . . . . . . 107
9.7.6. <transcriptions> Element . . . . . . . . . . . . . . 107
9.7.7. <confusable-phrases> Element . . . . . . . . . . . . 107
9.8. DEFINE-GRAMMAR . . . . . . . . . . . . . . . . . . . . . 107
9.9. RECOGNIZE . . . . . . . . . . . . . . . . . . . . . . . 111
9.10. STOP . . . . . . . . . . . . . . . . . . . . . . . . . . 118
9.11. GET-RESULT . . . . . . . . . . . . . . . . . . . . . . . 119
9.12. START-OF-INPUT . . . . . . . . . . . . . . . . . . . . . 120
9.13. START-INPUT-TIMERS . . . . . . . . . . . . . . . . . . . 120
9.14. RECOGNITION-COMPLETE . . . . . . . . . . . . . . . . . . 120
9.15. START-PHRASE-ENROLLMENT . . . . . . . . . . . . . . . . 123
9.16. ENROLLMENT-ROLLBACK . . . . . . . . . . . . . . . . . . 124
9.17. END-PHRASE-ENROLLMENT . . . . . . . . . . . . . . . . . 124
9.18. MODIFY-PHRASE . . . . . . . . . . . . . . . . . . . . . 125
9.19. DELETE-PHRASE . . . . . . . . . . . . . . . . . . . . . 125
9.20. INTERPRET . . . . . . . . . . . . . . . . . . . . . . . 125
9.21. INTERPRETATION-COMPLETE . . . . . . . . . . . . . . . . 127
9.22. DTMF Detection . . . . . . . . . . . . . . . . . . . . . 128
10. Recorder Resource . . . . . . . . . . . . . . . . . . . . . . 129
10.1. Recorder State Machine . . . . . . . . . . . . . . . . . 129
10.2. Recorder Methods . . . . . . . . . . . . . . . . . . . . 130
10.3. Recorder Events . . . . . . . . . . . . . . . . . . . . 130
10.4. Recorder Header Fields . . . . . . . . . . . . . . . . . 130
10.4.1. Sensitivity-Level . . . . . . . . . . . . . . . . . 130
10.4.2. No-Input-Timeout . . . . . . . . . . . . . . . . . . 131
10.4.3. Completion-Cause . . . . . . . . . . . . . . . . . . 131
10.4.4. Completion-Reason . . . . . . . . . . . . . . . . . 132
10.4.5. Failed-URI . . . . . . . . . . . . . . . . . . . . . 132
10.4.6. Failed-URI-Cause . . . . . . . . . . . . . . . . . . 132
10.4.7. Record-URI . . . . . . . . . . . . . . . . . . . . . 132
10.4.8. Media-Type . . . . . . . . . . . . . . . . . . . . . 133
10.4.9. Max-Time . . . . . . . . . . . . . . . . . . . . . . 133
10.4.10. Trim-Length . . . . . . . . . . . . . . . . . . . . 134
10.4.11. Final-Silence . . . . . . . . . . . . . . . . . . . 134
10.4.12. Capture-On-Speech . . . . . . . . . . . . . . . . . 134
10.4.13. Ver-Buffer-Utterance . . . . . . . . . . . . . . . . 134
10.4.14. Start-Input-Timers . . . . . . . . . . . . . . . . . 135
10.4.15. New-Audio-Channel . . . . . . . . . . . . . . . . . 135
10.5. Recorder Message Body . . . . . . . . . . . . . . . . . 135
10.6. RECORD . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.7. STOP . . . . . . . . . . . . . . . . . . . . . . . . . . 136
10.8. RECORD-COMPLETE . . . . . . . . . . . . . . . . . . . . 137
10.9. START-INPUT-TIMERS . . . . . . . . . . . . . . . . . . . 138
10.10. START-OF-INPUT . . . . . . . . . . . . . . . . . . . . . 138
11. Speaker Verification and Identification . . . . . . . . . . . 139
11.1. Speaker Verification State Machine . . . . . . . . . . . 140
11.2. Speaker Verification Methods . . . . . . . . . . . . . . 142
11.3. Verification Events . . . . . . . . . . . . . . . . . . 144
11.4. Verification Header Fields . . . . . . . . . . . . . . . 144
11.4.1. Repository-URI . . . . . . . . . . . . . . . . . . . 144
11.4.2. Voiceprint-Identifier . . . . . . . . . . . . . . . 145
11.4.3. Verification-Mode . . . . . . . . . . . . . . . . . 145
11.4.4. Adapt-Model . . . . . . . . . . . . . . . . . . . . 146
11.4.5. Abort-Model . . . . . . . . . . . . . . . . . . . . 146
11.4.6. Min-Verification-Score . . . . . . . . . . . . . . . 147
11.4.7. Num-Min-Verification-Phrases . . . . . . . . . . . . 147
11.4.8. Num-Max-Verification-Phrases . . . . . . . . . . . . 147
11.4.9. No-Input-Timeout . . . . . . . . . . . . . . . . . . 148
11.4.10. Save-Waveform . . . . . . . . . . . . . . . . . . . 148
11.4.11. Media-Type . . . . . . . . . . . . . . . . . . . . . 148
11.4.12. Waveform-URI . . . . . . . . . . . . . . . . . . . . 148
11.4.13. Voiceprint-Exists . . . . . . . . . . . . . . . . . 149
11.4.14. Ver-Buffer-Utterance . . . . . . . . . . . . . . . . 149
11.4.15. Input-Waveform-URI . . . . . . . . . . . . . . . . . 149
11.4.16. Completion-Cause . . . . . . . . . . . . . . . . . . 150
11.4.17. Completion-Reason . . . . . . . . . . . . . . . . . 151
11.4.18. Speech-Complete-Timeout . . . . . . . . . . . . . . 151
11.4.19. New-Audio-Channel . . . . . . . . . . . . . . . . . 152
11.4.20. Abort-Verification . . . . . . . . . . . . . . . . . 152
11.4.21. Start-Input-Timers . . . . . . . . . . . . . . . . . 152
11.5. Verification Message Body . . . . . . . . . . . . . . . 152
11.5.1. Verification Result Data . . . . . . . . . . . . . . 152
11.5.2. Verification Result Elements . . . . . . . . . . . . 153
11.6. START-SESSION . . . . . . . . . . . . . . . . . . . . . 157
11.7. END-SESSION . . . . . . . . . . . . . . . . . . . . . . 158
11.8. QUERY-VOICEPRINT . . . . . . . . . . . . . . . . . . . . 159
11.9. DELETE-VOICEPRINT . . . . . . . . . . . . . . . . . . . 160
11.10. VERIFY . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.11. VERIFY-FROM-BUFFER . . . . . . . . . . . . . . . . . . . 160
11.12. VERIFY-ROLLBACK . . . . . . . . . . . . . . . . . . . . 164
11.13. STOP . . . . . . . . . . . . . . . . . . . . . . . . . . 164
11.14. START-INPUT-TIMERS . . . . . . . . . . . . . . . . . . . 165
11.15. VERIFICATION-COMPLETE . . . . . . . . . . . . . . . . . 165
11.16. START-OF-INPUT . . . . . . . . . . . . . . . . . . . . . 166
11.17. CLEAR-BUFFER . . . . . . . . . . . . . . . . . . . . . . 166
11.18. GET-INTERMEDIATE-RESULT . . . . . . . . . . . . . . . . 167
12. Security Considerations . . . . . . . . . . . . . . . . . . . 168
12.1. Rendezvous and Session Establishment . . . . . . . . . . 168
12.2. Control Channel Protection . . . . . . . . . . . . . . . 168
12.3. Media Session Protection . . . . . . . . . . . . . . . . 169
12.4. Indirect Content Access . . . . . . . . . . . . . . . . 169
12.5. Protection of Stored Media . . . . . . . . . . . . . . . 170
12.6. DTMF and Recognition Buffers . . . . . . . . . . . . . . 171
12.7. Client-Set Server Parameters . . . . . . . . . . . . . . 171
12.8. DELETE-VOICEPRINT and Authorization . . . . . . . . . . 171
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 171
13.1. New Registries . . . . . . . . . . . . . . . . . . . . . 171
13.1.1. MRCPv2 Resource Types . . . . . . . . . . . . . . . 171
13.1.2. MRCPv2 Methods and Events . . . . . . . . . . . . . 172
13.1.3. MRCPv2 Header Fields . . . . . . . . . . . . . . . . 173
13.1.4. MRCPv2 Status Codes . . . . . . . . . . . . . . . . 176
13.1.5. Grammar Reference List Parameters . . . . . . . . . 176
13.1.6. MRCPv2 Vendor-Specific Parameters . . . . . . . . . 176
13.2. NLSML-Related Registrations . . . . . . . . . . . . . . 177
13.2.1. 'application/nlsml+xml' Media Type Registration . . 177
13.3. NLSML XML Schema Registration . . . . . . . . . . . . . 178
13.4. MRCPv2 XML Namespace Registration . . . . . . . . . . . 178
13.5. Text Media Type Registrations . . . . . . . . . . . . . 178
13.5.1. text/grammar-ref-list . . . . . . . . . . . . . . . 178
13.6. 'session' URI Scheme Registration . . . . . . . . . . . 180
13.7. SDP Parameter Registrations . . . . . . . . . . . . . . 181
13.7.1. Sub-Registry "proto" . . . . . . . . . . . . . . . . 181
13.7.2. Sub-Registry "att-field (media-level)" . . . . . . . 182
14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 183
14.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . 183
14.2. Recognition Result Examples . . . . . . . . . . . . . . 192
14.2.1. Simple ASR Ambiguity . . . . . . . . . . . . . . . . 192
14.2.2. Mixed Initiative . . . . . . . . . . . . . . . . . . 192
14.2.3. DTMF Input . . . . . . . . . . . . . . . . . . . . . 193
14.2.4. Interpreting Meta-Dialog and Meta-Task Utterances . 194
14.2.5. Anaphora and Deixis . . . . . . . . . . . . . . . . 195
14.2.6. Distinguishing Individual Items from Sets with
One Member . . . . . . . . . . . . . . . . . . . . . 195
14.2.7. Extensibility . . . . . . . . . . . . . . . . . . . 196
15. ABNF Normative Definition . . . . . . . . . . . . . . . . . . 196
16. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 211
16.1. NLSML Schema Definition . . . . . . . . . . . . . . . . 211
16.2. Enrollment Results Schema Definition . . . . . . . . . . 213
16.3. Verification Results Schema Definition . . . . . . . . . 214
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 218
17.1. Normative References . . . . . . . . . . . . . . . . . . 218
17.2. Informative References . . . . . . . . . . . . . . . . . 220
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 223
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 223
MRCPv2 is designed to allow a client device to control media processing resources on the network. Some of these media processing resources include speech recognition engines, speech synthesis engines, speaker verification, and speaker identification engines. MRCPv2 enables the implementation of distributed Interactive Voice Response platforms using VoiceXML [W3C.REC-voicexml20-20040316] browsers or other client applications while maintaining separate back-end speech processing capabilities on specialized speech processing servers. MRCPv2 is based on the earlier Media Resource Control Protocol (MRCP) [RFC4463] developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. Although some of the method names are similar, the way in which these methods are communicated is different. There are also more resources and more methods for each resource. The first version of MRCP was essentially taken only as input to the development of this protocol. There is no expectation that an MRCPv2 client will work with an MRCPv1 server or vice versa. There is no migration plan or gateway definition between the two protocols.
MRCPv2は、クライアントデバイスがネットワーク上のメディア処理リソースを制御できるように設計されています。これらのメディア処理リソースには、音声認識エンジン、音声合成エンジン、話者認証、話者識別エンジンなどがあります。 MRCPv2は、VoiceXML [W3C.REC-voicexml20-20040316]ブラウザまたは他のクライアントアプリケーションを使用して、分散型音声自動応答プラットフォームの実装を可能にすると同時に、専用の音声処理サーバーで個別のバックエンド音声処理機能を維持します。 MRCPv2は、Cisco Systems、Inc.、Nuance Communications、およびSpeechworks、Incが共同で開発した以前のメディアリソースコントロールプロトコル（MRCP）[RFC4463]に基づいています。メソッド名の一部は類似していますが、これらのメソッドが通信される方法違います。各リソースには、より多くのリソースとメソッドもあります。 MRCPの最初のバージョンは、基本的にこのプロトコルの開発への入力としてのみ採用されました。 MRCPv2クライアントがMRCPv1サーバーで動作すること、またはその逆が期待されることはありません。 2つのプロトコルの間に移行計画またはゲートウェイ定義はありません。
The protocol requirements of Speech Services Control (SPEECHSC) [RFC4313] include that the solution be capable of reaching a media processing server, setting up communication channels to the media resources, and sending and receiving control messages and media streams to/from the server. The Session Initiation Protocol (SIP) [RFC3261] meets these requirements.
Speech Services Control（SPEECHSC）[RFC4313]のプロトコル要件には、ソリューションがメディア処理サーバーに到達し、メディアリソースへの通信チャネルを設定し、サーバーとの間で制御メッセージとメディアストリームを送受信できることが含まれます。セッション開始プロトコル（SIP）[RFC3261]はこれらの要件を満たしています。
The proprietary version of MRCP ran over the Real Time Streaming Protocol (RTSP) [RFC2326]. At the time work on MRCPv2 was begun, the consensus was that this use of RTSP would break the RTSP protocol or cause backward-compatibility problems, something forbidden by Section 3.2 of [RFC4313]. This is the reason why MRCPv2 does not run over RTSP.
MRCPのプロプライエタリバージョンは、リアルタイムストリーミングプロトコル（RTSP）[RFC2326]で実行されました。 MRCPv2の作業が開始された時点では、このRTSPの使用はRTSPプロトコルを破壊するか、後方互換性の問題を引き起こすという合意がありました。これは、[RFC4313]のセクション3.2で禁止されています。これが、MRCPv2がRTSP上で実行されない理由です。
MRCPv2 leverages these capabilities by building upon SIP and the Session Description Protocol (SDP) [RFC4566]. MRCPv2 uses SIP to set up and tear down media and control sessions with the server. In addition, the client can use a SIP re-INVITE method (an INVITE dialog sent within an existing SIP session) to change the characteristics of these media and control session while maintaining the SIP dialog between the client and server. SDP is used to describe the parameters of the media sessions associated with that dialog. It is mandatory to support SIP as the session establishment protocol to ensure interoperability. Other protocols can be used for session establishment by prior agreement. This document only describes the use of SIP and SDP.
MRCPv2は、SIPおよびセッション記述プロトコル（SDP）[RFC4566]に基づいてこれらの機能を活用します。 MRCPv2はSIPを使用して、メディアのセットアップと破棄、およびサーバーとのセッションの制御を行います。さらに、クライアントはSIP re-INVITEメソッド（既存のSIPセッション内で送信されるINVITEダイアログ）を使用して、クライアントとサーバー間のSIPダイアログを維持しながら、これらのメディアと制御セッションの特性を変更できます。 SDPは、そのダイアログに関連付けられたメディアセッションのパラメーターを記述するために使用されます。相互運用性を確保するには、セッション確立プロトコルとしてSIPをサポートする必要があります。事前の合意により、他のプロトコルをセッションの確立に使用できます。このドキュメントでは、SIPおよびSDPの使用についてのみ説明します。
MRCPv2 uses SIP and SDP to create the speech client/server dialog and set up the media channels to the server. It also uses SIP and SDP to establish MRCPv2 control sessions between the client and the server for each media processing resource required for that dialog. The MRCPv2 protocol exchange between the client and the media resource is carried on that control session. MRCPv2 exchanges do not change the state of the SIP dialog, the media sessions, or other parameters of the dialog initiated via SIP. It controls and affects the state of the media processing resource associated with the MRCPv2 session(s).
MRCPv2はSIPおよびSDPを使用して、スピーチクライアント/サーバーダイアログを作成し、サーバーへのメディアチャネルをセットアップします。また、SIPおよびSDPを使用して、そのダイアログに必要なメディア処理リソースごとに、クライアントとサーバー間のMRCPv2制御セッションを確立します。クライアントとメディアリソース間のMRCPv2プロトコル交換は、その制御セッションで行われます。 MRCPv2交換では、SIPダイアログ、メディアセッション、またはSIPを介して開始されたダイアログの他のパラメータの状態は変更されません。これは、MRCPv2セッションに関連付けられたメディア処理リソースの状態を制御および影響します。
MRCPv2 defines the messages to control the different media processing resources and the state machines required to guide their operation. It also describes how these messages are carried over a transport-layer protocol such as the Transmission Control Protocol (TCP) [RFC0793] or the Transport Layer Security (TLS) Protocol [RFC5246]. (Note: the Stream Control Transmission Protocol (SCTP) [RFC4960] is a viable transport for MRCPv2 as well, but the mapping onto SCTP is not described in this specification.)
MRCPv2は、さまざまなメディア処理リソースと、それらの操作をガイドするために必要なステートマシンを制御するメッセージを定義します。また、これらのメッセージが伝送制御プロトコル（TCP）[RFC0793]やトランスポート層セキュリティ（TLS）プロトコル[RFC5246]などのトランスポート層プロトコルでどのように伝送されるかについても説明します。 （注：ストリーム制御伝送プロトコル（SCTP）[RFC4960]もMRCPv2の実行可能なトランスポートですが、SCTPへのマッピングはこの仕様では説明されていません。）
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Since many of the definitions and syntax are identical to those for the Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616], this specification refers to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of RFC 2616.
定義と構文の多くは、Hypertext Transfer Protocol-HTTP / 1.1 [RFC2616]の定義と構文と同じであるため、この仕様は、コピーではなく定義されているセクションを参照します。簡潔にするために、[HX.Y]はRFC 2616のセクションX.Yを参照すると解釈されます。
All the mechanisms specified in this document are described in both prose and an augmented Backus-Naur form (ABNF [RFC5234]).
このドキュメントで指定されているすべてのメカニズムは、散文と拡張バッカスナウア形式（ABNF [RFC5234]）の両方で説明されています。
The complete message format in ABNF form is provided in Section 15 and is the normative format definition. Note that productions may be duplicated within the main body of the document for reading convenience. If a production in the body of the text conflicts with one in the normative definition, the latter rules.
ABNF形式の完全なメッセージ形式はセクション15で提供されており、規範的な形式の定義です。読みやすいように、プロダクションはドキュメントの本文内で複製される場合があることに注意してください。テキスト本文のプロダクションが規範的定義のプロダクションと矛盾する場合は、後者が適用されます。
Media Resource An entity on the speech processing server that can be controlled through MRCPv2.
メディアリソースMRCPv2を介して制御できる音声処理サーバー上のエンティティ。
MRCP Server Aggregate of one or more "Media Resource" entities on a server, exposed through MRCPv2. Often, 'server' in this document refers to an MRCP server.
MRCPサーバーサーバー上の1つ以上の「メディアリソース」エンティティの集合体。MRCPv2を通じて公開されます。多くの場合、このドキュメントの「サーバー」はMRCPサーバーを指します。
MRCP Client An entity controlling one or more Media Resources through MRCPv2 ("Client" for short).
MRCPクライアントMRCPv2（略して「クライアント」）を介して1つ以上のメディアリソースを制御するエンティティ。
DTMF Dual-Tone Multi-Frequency; a method of transmitting key presses in-band, either as actual tones (Q.23 [Q.23]) or as named tone events (RFC 4733 [RFC4733]).
DTMFデュアルトーンマルチ周波数;キープレスをインバンドで、実際のトーン（Q.23 [Q.23]）または名前付きトーンイベント（RFC 4733 [RFC4733]）として送信する方法。
Endpointing The process of automatically detecting the beginning and end of speech in an audio stream. This is critical both for speech recognition and for automated recording as one would find in voice mail systems.
エンドポイント化オーディオストリームの音声の始まりと終わりを自動的に検出するプロセス。これは、音声認識とボイスメールシステムで見られる自動録音の両方にとって重要です。
Hotword Mode A mode of speech recognition where a stream of utterances is evaluated for match against a small set of command words. This is generally employed either to trigger some action or to control the subsequent grammar to be used for further recognition.
ホットワードモード発話のストリームがコマンドワードの小さなセットとの一致について評価される音声認識のモード。これは一般に、何らかのアクションをトリガーするため、またはその後の認識に使用される後続の文法を制御するために使用されます。
The state-machine diagrams in this document do not show every possible method call. Rather, they reflect the state of the resource based on the methods that have moved to IN-PROGRESS or COMPLETE states (see Section 5.3). Note that since PENDING requests essentially have not affected the resource yet and are in the queue to be processed, they are not reflected in the state-machine diagrams.
このドキュメントの状態マシン図は、可能なすべてのメソッド呼び出しを示しているわけではありません。むしろ、IN-PROGRESS状態またはCOMPLETE状態に移行したメソッドに基づいてリソースの状態を反映します（セクション5.3を参照）。 PENDINGリクエストは基本的にまだリソースに影響を与えておらず、処理されるキューにあるため、それらは状態マシン図に反映されないことに注意してください。
This document defines many protocol headers that contain URIs (Uniform Resource Identifiers [RFC3986]) or lists of URIs for referencing media. The entire document, including the Security Considerations section (Section 12), assumes that HTTP or HTTP over TLS (HTTPS) [RFC2818] will be used as the URI addressing scheme unless otherwise stated. However, implementations MAY support other schemes (such as 'file'), provided they have addressed any security considerations described in this document and any others particular to the specific scheme. For example, implementations where the client and server both reside on the same physical hardware and the file system is secured by traditional user-level file access controls could be reasonable candidates for supporting the 'file' scheme.
このドキュメントでは、URI（Uniform Resource Identifiers [RFC3986]）またはメディアを参照するためのURIのリストを含む多くのプロトコルヘッダーを定義しています。 「セキュリティに関する考慮事項」セクション（セクション12）を含むドキュメント全体では、特に明記されていない限り、HTTPまたはHTTP over TLS（HTTPS）[RFC2818]がURIアドレス指定スキームとして使用されることを前提としています。ただし、実装が他のスキーム（「ファイル」など）をサポートする場合があります（ただし、それらがこのドキュメントで説明されているセキュリティ上の考慮事項および特定のスキームに固有のその他の考慮事項に対処している場合）。たとえば、クライアントとサーバーの両方が同じ物理ハードウェア上にあり、ファイルシステムが従来のユーザーレベルのファイルアクセス制御によって保護されている実装は、「ファイル」スキームをサポートするための合理的な候補となります。
A system using MRCPv2 consists of a client that requires the generation and/or consumption of media streams and a media resource server that has the resources or "engines" to process these streams as input or generate these streams as output. The client uses SIP and SDP to establish an MRCPv2 control channel with the server to use its media processing resources. MRCPv2 servers are addressed using SIP URIs.
MRCPv2を使用するシステムは、メディアストリームの生成や消費を必要とするクライアントと、これらのストリームを入力として処理したり、これらのストリームを出力として生成したりするリソースまたは「エンジン」を備えたメディアリソースサーバーで構成されます。クライアントはSIPおよびSDPを使用して、サーバーとのMRCPv2制御チャネルを確立し、メディア処理リソースを使用します。 MRCPv2サーバーは、SIP URIを使用してアドレス指定されます。
SIP uses SDP with the offer/answer model described in RFC 3264 [RFC3264] to set up the MRCPv2 control channels and describe their characteristics. A separate MRCPv2 session is needed to control each of the media processing resources associated with the SIP dialog between the client and server. Within a SIP dialog, the individual resource control channels for the different resources are added or removed through SDP offer/answer carried in a SIP re-INVITE transaction.
SIPは、RFC 3264 [RFC3264]で説明されているオファー/アンサーモデルでSDPを使用して、MRCPv2制御チャネルをセットアップし、それらの特性を記述します。クライアントとサーバー間のSIPダイアログに関連する各メディア処理リソースを制御するには、個別のMRCPv2セッションが必要です。 SIPダイアログ内では、さまざまなリソースの個々のリソース制御チャネルが、SIP re-INVITEトランザクションで伝送されるSDPオファー/アンサーを通じて追加または削除されます。
The server, through the SDP exchange, provides the client with a difficult-to-guess, unambiguous channel identifier and a TCP port number (see Section 4.2). The client MAY then open a new TCP connection with the server on this port number. Multiple MRCPv2 channels can share a TCP connection between the client and the server. All MRCPv2 messages exchanged between the client and the server carry the specified channel identifier that the server MUST ensure is unambiguous among all MRCPv2 control channels that are active on that server. The client uses this channel identifier to indicate the media processing resource associated with that channel. For information on message framing, see Section 5.
サーバーは、SDP交換を介して、推測が困難で明確なチャネル識別子とTCPポート番号をクライアントに提供します（セクション4.2を参照）。次に、クライアントはこのポート番号でサーバーとの新しいTCP接続を開くことができます。複数のMRCPv2チャネルは、クライアントとサーバー間でTCP接続を共有できます。クライアントとサーバー間で交換されるすべてのMRCPv2メッセージは、サーバーがそのサーバーでアクティブなすべてのMRCPv2制御チャネル間で明確であることを保証しなければならない指定されたチャネル識別子を運ぶ。クライアントはこのチャネル識別子を使用して、そのチャネルに関連付けられているメディア処理リソースを示します。メッセージのフレーミングについては、セクション5を参照してください。
SIP also establishes the media sessions between the client (or other source/sink of media) and the MRCPv2 server using SDP "m=" lines.
SIPは、SDP "m ="行を使用して、クライアント（または他のメディアのソース/シンク）とMRCPv2サーバーの間のメディアセッションも確立します。
One or more media processing resources may share a media session under a SIP session, or each media processing resource may have its own media session.
1つ以上のメディア処理リソースがSIPセッションでメディアセッションを共有する場合や、各メディア処理リソースが独自のメディアセッションを持つ場合があります。
The following diagram shows the general architecture of a system that uses MRCPv2. To simplify the diagram, only a few resources are shown.
次の図は、MRCPv2を使用するシステムの一般的なアーキテクチャを示しています。図を簡略化するために、いくつかのリソースのみを示しています。
MRCPv2 client MRCPv2 Media Resource Server
|--------------------| |------------------------------------|
||------------------|| ||----------------------------------||
|| Application Layer|| ||Synthesis|Recognition|Verification||
||------------------|| || Engine | Engine | Engine ||
||Media Resource API|| || || | || | || ||
||------------------|| ||Synthesis|Recognizer | Verifier ||
|| SIP | MRCPv2 || ||Resource | Resource | Resource ||
||Stack | || || Media Resource Management ||
|| | || ||----------------------------------||
||------------------|| || SIP | MRCPv2 ||
|| TCP/IP Stack ||---MRCPv2---|| Stack | ||
|| || ||----------------------------------||
||------------------||----SIP-----|| TCP/IP Stack ||
|--------------------| || ||
| ||----------------------------------||
SIP |------------------------------------|
| /
|-------------------| RTP
| | /
| Media Source/Sink |------------/
| |
|-------------------|
Figure 1: Architectural Diagram
図1：アーキテクチャ図
An MRCPv2 server may offer one or more of the following media processing resources to its clients.
MRCPv2サーバーは、次のメディア処理リソースの1つ以上をクライアントに提供します。
Basic Synthesizer A speech synthesizer resource that has very limited capabilities and can generate its media stream exclusively from concatenated audio clips. The speech data is described using a limited subset of the Speech Synthesis Markup Language (SSML) [W3C.REC-speech-synthesis-20040907] elements. A basic synthesizer MUST support the SSML tags <speak>, <audio>, <say-as>, and <mark>.
基本シンセサイザ機能が非常に制限され、連結オーディオクリップからのみメディアストリームを生成できる音声シンセサイザリソース。音声データは、音声合成マークアップ言語（SSML）[W3C.REC-speech-synthesis-20040907]要素の限定されたサブセットを使用して記述されます。基本的なシンセサイザは、SSMLタグ<speak>、<audio>、<say-as>、および<mark>をサポートする必要があります。
Speech Synthesizer A full-capability speech synthesis resource that can render speech from text. Such a synthesizer MUST have full SSML [W3C.REC-speech-synthesis-20040907] support.
Speech Synthesizerテキストから音声をレンダリングできるフル機能の音声合成リソース。そのようなシンセサイザは、完全なSSML [W3C.REC-speech-synthesis-20040907]をサポートしている必要があります。
Recorder A resource capable of recording audio and providing a URI pointer to the recording. A recorder MUST provide endpointing capabilities for suppressing silence at the beginning and end of a recording, and MAY also suppress silence in the middle of a recording. If such suppression is done, the recorder MUST maintain timing metadata to indicate the actual timestamps of the recorded media.
レコーダーオーディオを録音し、録音へのURIポインターを提供できるリソース。レコーダーは、録音の開始時と終了時の無音を抑制するためのエンドポイント機能を提供する必要があります。また、録音の途中の無音も抑制できます（MAY）。そのような抑制が行われる場合、レコーダーは記録されたメディアの実際のタイムスタンプを示すためにタイミングメタデータを維持しなければなりません。
DTMF Recognizer A recognizer resource capable of extracting and interpreting Dual-Tone Multi-Frequency (DTMF) [Q.23] digits in a media stream and matching them against a supplied digit grammar. It could also do a semantic interpretation based on semantic tags in the grammar.
DTMFレコグナイザーメディアストリーム内のデュアルトーンマルチ周波数（DTMF）[Q.23]ディジットを抽出および解釈し、それらを指定されたディジット文法と照合できるレコグナイザーリソース。また、文法のセマンティックタグに基づいてセマンティック解釈を行うこともできます。
Speech Recognizer A full speech recognition resource that is capable of receiving a media stream containing audio and interpreting it to recognition results. It also has a natural language semantic interpreter to post-process the recognized data according to the semantic data in the grammar and provide semantic results along with the recognized input. The recognizer MAY also support enrolled grammars, where the client can enroll and create new personal grammars for use in future recognition operations.
Speech Recognizer音声を含むメディアストリームを受信して認識結果に解釈できる完全な音声認識リソース。また、文法のセマンティックデータに従って認識されたデータを後処理し、認識された入力とともにセマンティックな結果を提供する自然言語セマンティックインタープリターも備えています。レコグナイザは、登録された文法もサポートしてもよい（MAY）。クライアントは、将来の認識操作で使用するために新しい個人の文法を登録および作成できます。
Speaker Verifier A resource capable of verifying the authenticity of a claimed identity by matching a media stream containing spoken input to a pre-existing voiceprint. This may also involve matching the caller's voice against more than one voiceprint, also called multi-verification or speaker identification.
Speaker Verifier音声入力を含むメディアストリームを既存の声紋と照合することにより、主張されたIDの信頼性を検証できるリソース。これには、発信者の声を複数の声紋と照合することも含まれます。これは、マルチ検証または話者識別とも呼ばれます。
The MRCPv2 server is a generic SIP server, and is thus addressed by a SIP URI (RFC 3261 [RFC3261]).
MRCPv2サーバーは一般的なSIPサーバーであるため、SIP URI（RFC 3261 [RFC3261]）によってアドレス指定されます。
For example:
例えば：
sip:mrcpv2@example.net or
sips:mrcpv2@example.net
MRCPv2 requires a connection-oriented transport-layer protocol such as TCP to guarantee reliable sequencing and delivery of MRCPv2 control messages between the client and the server. In order to meet the requirements for security enumerated in SPEECHSC requirements [RFC4313], clients and servers MUST implement TLS as well. One or more connections between the client and the server can be shared among different MRCPv2 channels to the server. The individual messages carry the channel identifier to differentiate messages on different channels. MRCPv2 encoding is text based with mechanisms to carry embedded binary data. This allows arbitrary data like recognition grammars, recognition results, synthesizer speech markup, etc., to be carried in MRCPv2 messages. For information on message framing, see Section 5.
MRCPv2には、クライアントとサーバー間のMRCPv2制御メッセージの信頼性の高いシーケンスと配信を保証するために、TCPなどの接続指向のトランスポート層プロトコルが必要です。 SPEECHSC要件[RFC4313]に列挙されているセキュリティの要件を満たすために、クライアントとサーバーもTLSを実装する必要があります。クライアントとサーバー間の1つ以上の接続を、サーバーへの異なるMRCPv2チャネル間で共有できます。個々のメッセージは、異なるチャネル上のメッセージを区別するためにチャネル識別子を持っています。 MRCPv2エンコーディングは、埋め込まれたバイナリデータを伝送するメカニズムを備えたテキストベースです。これにより、認識文法、認識結果、シンセサイザ音声マークアップなどの任意のデータをMRCPv2メッセージで伝送できます。メッセージのフレーミングについては、セクション5を参照してください。
MRCPv2 employs SIP, in conjunction with SDP, as the session establishment and management protocol. The client reaches an MRCPv2 server using conventional INVITE and other SIP requests for establishing, maintaining, and terminating SIP dialogs. The SDP offer/answer exchange model over SIP is used to establish a resource control channel for each resource. The SDP offer/answer exchange is also used to establish media sessions between the server and the source or sink of audio.
MRCPv2は、SDPとともにSIPをセッションの確立および管理プロトコルとして採用しています。クライアントは、SIPダイアログを確立、維持、および終了するための従来のINVITEおよびその他のSIP要求を使用してMRCPv2サーバーに到達します。 SIPを介したSDPオファー/アンサー交換モデルは、各リソースのリソース制御チャネルを確立するために使用されます。 SDPオファー/アンサー交換は、サーバーとオーディオのソースまたはシンクとの間にメディアセッションを確立するためにも使用されます。
The client needs a separate MRCPv2 resource control channel to control each media processing resource under the SIP dialog. A unique channel identifier string identifies these resource control channels. The channel identifier is a difficult-to-guess, unambiguous string followed by an "@", then by a string token specifying the type of resource. The server generates the channel identifier and MUST make sure it does not clash with the identifier of any other MRCP channel currently allocated by that server. MRCPv2 defines the following IANA-registered types of media processing resources. Additional resource types and their associated methods/ events and state machines may be added as described below in Section 13.
クライアントは、SIPダイアログの下で各メディア処理リソースを制御するために、別個のMRCPv2リソース制御チャネルを必要とします。一意のチャネル識別子文字列は、これらのリソース制御チャネルを識別します。チャネルIDは、推測が困難で明確な文字列の後に「@」が続き、その後にリソースのタイプを指定する文字列トークンが続きます。サーバーはチャネル識別子を生成し、そのサーバーによって現在割り当てられている他のMRCPチャネルの識別子と競合しないことを確認する必要があります。 MRCPv2は、次のIANA登録タイプのメディア処理リソースを定義します。以下のセクション13で説明するように、追加のリソースタイプとそれに関連するメソッド/イベントおよびステートマシンを追加できます。
+---------------+----------------------+--------------+
| Resource Type | Resource Description | Described in |
+---------------+----------------------+--------------+
| speechrecog | Speech Recognizer | Section 9 |
| dtmfrecog | DTMF Recognizer | Section 9 |
| speechsynth | Speech Synthesizer | Section 8 |
| basicsynth | Basic Synthesizer | Section 8 |
| speakverify | Speaker Verification | Section 11 |
| recorder | Speech Recorder | Section 10 |
+---------------+----------------------+--------------+
Table 1: Resource Types
表1：リソースタイプ
The SIP INVITE or re-INVITE transaction and the SDP offer/answer exchange it carries contain "m=" lines describing the resource control channel to be allocated. There MUST be one SDP "m=" line for each MRCPv2 resource to be used in the session. This "m=" line MUST have a media type field of "application" and a transport type field of either "TCP/MRCPv2" or "TCP/TLS/MRCPv2". The port number field of the "m=" line MUST contain the "discard" port of the transport protocol (port 9 for TCP) in the SDP offer from the client and MUST contain the TCP listen port on the server in the SDP answer. The client may then either set up a TCP or TLS connection to that server port or share an already established connection to that port. Since MRCPv2 allows multiple sessions to share the same TCP connection, multiple "m=" lines in a single SDP document MAY share the same port field value; MRCPv2 servers MUST NOT assume any relationship between resources using the same port other than the sharing of the communication channel.
SIP INVITEまたはre-INVITEトランザクション、およびそれが運ぶSDPオファー/アンサー交換には、割り当てられるリソース制御チャネルを説明する「m =」行が含まれています。セッションで使用するMRCPv2リソースごとに1つのSDP "m ="行が必要です。この「m =」行には、「アプリケーション」のメディアタイプフィールドと「TCP / MRCPv2」または「TCP / TLS / MRCPv2」のトランスポートタイプフィールドが必要です。 「m =」行のポート番号フィールドには、クライアントからのSDPオファーのトランスポートプロトコル（TCPのポート9）の「破棄」ポートが含まれている必要があり、SDP応答のサーバーのTCPリッスンポートが含まれている必要があります。次に、クライアントは、そのサーバーポートへのTCPまたはTLS接続をセットアップするか、すでに確立されているそのポートへの接続を共有します。 MRCPv2では複数のセッションで同じTCP接続を共有できるため、単一のSDPドキュメント内の複数の「m =」行が同じポートフィールド値を共有する場合があります。 MRCPv2サーバーは、通信チャネルの共有以外の同じポートを使用するリソース間の関係を想定してはなりません（MUST NOT）。
MRCPv2 resources do not use the port or format field of the "m=" line to distinguish themselves from other resources using the same channel. The client MUST specify the resource type identifier in the resource attribute associated with the control "m=" line of the SDP offer. The server MUST respond with the full Channel-Identifier (which includes the resource type identifier and a difficult-to-guess, unambiguous string) in the "channel" attribute associated with the control "m=" line of the SDP answer. To remain backwards compatible with conventional SDP usage, the format field of the "m=" line MUST have the arbitrarily selected value of "1".
MRCPv2リソースは、「m =」行のポートまたはフォーマットフィールドを使用して、同じチャネルを使用する他のリソースと区別しません。クライアントは、SDPオファーのコントロール「m =」行に関連付けられたリソース属性でリソースタイプ識別子を指定する必要があります。サーバーは、SDP回答のコントロール「m =」行に関連付けられた「channel」属性の完全なChannel-Identifier（リソースタイプ識別子と推測が難しい、明確な文字列を含む）で応答する必要があります。従来のSDPの使用との下位互換性を維持するには、「m =」行のフォーマットフィールドに任意に選択された「1」の値が必要です。
When the client wants to add a media processing resource to the session, it issues a new SDP offer, according to the procedures of RFC 3264 [RFC3264], in a SIP re-INVITE request. The SDP offer/answer exchange carried by this SIP transaction contains one or more additional control "m=" lines for the new resources to be allocated to the session. The server, on seeing the new "m=" line, allocates the resources (if they are available) and responds with a corresponding control "m=" line in the SDP answer carried in the SIP response. If the new resources are not available, the re-INVITE receives an error message, and existing media processing going on before the re-INVITE will continue as it was before. It is not possible to allocate more than one resource of each type. If a client requests more than one resource of any type, the server MUST behave as if the resources of that type (beyond the first one) are not available.
クライアントがメディア処理リソースをセッションに追加する場合、RFC 3264 [RFC3264]の手順に従って、SIP re-INVITEリクエストで新しいSDPオファーを発行します。このSIPトランザクションによって実行されるSDPオファー/アンサー交換には、セッションに割り当てられる新しいリソース用の1つ以上の追加の制御 "m ="行が含まれています。サーバーは、新しい "m ="行を確認すると、リソースを割り当て（使用可能な場合）、SIP応答で伝送されるSDP応答の対応する制御 "m ="行で応答します。新しいリソースが利用できない場合、re-INVITEはエラーメッセージを受け取り、re-INVITEの前に進行中の既存のメディア処理は以前と同様に続行されます。各タイプの複数のリソースを割り当てることはできません。クライアントが任意のタイプの複数のリソースを要求する場合、サーバーはそのタイプのリソース（最初のリソース以外）が利用できないかのように動作する必要があります。
MRCPv2 clients and servers using TCP as a transport protocol MUST use the procedures specified in RFC 4145 [RFC4145] for setting up the TCP connection, with the considerations described hereby. Similarly, MRCPv2 clients and servers using TCP/TLS as a transport protocol MUST use the procedures specified in RFC 4572 [RFC4572] for setting up the TLS connection, with the considerations described hereby. The a=setup attribute, as described in RFC 4145 [RFC4145], MUST be "active" for the offer from the client and MUST be "passive" for the answer from the MRCPv2 server. The a=connection attribute MUST have a value of "new" on the very first control "m=" line offer from the client to an MRCPv2 server. Subsequent control "m=" line offers from the client to the MRCP server MAY contain "new" or "existing", depending on whether the client wants to set up a new connection or share an existing connection, respectively. If the client specifies a value of "new", the server MUST respond with a value of "new". If the client specifies a value of "existing", the server MUST respond. The legal values in the response are "existing" if the server prefers to share an existing connection or "new" if not. In the latter case, the client MUST initiate a new transport connection.
トランスポートプロトコルとしてTCPを使用するMRCPv2クライアントとサーバーは、RFC 4145 [RFC4145]で指定されている手順を使用して、TCP接続をセットアップする必要があります。同様に、TCP / TLSをトランスポートプロトコルとして使用するMRCPv2クライアントおよびサーバーは、TLS接続をセットアップするために、RFC 4572 [RFC4572]で指定されている手順を使用する必要があります。 RFC 4145 [RFC4145]で説明されているように、a = setup属性は、クライアントからのオファーに対して「アクティブ」である必要があり、MRCPv2サーバーからの回答に対して「パッシブ」である必要があります。 a = connection属性は、クライアントからMRCPv2サーバーへの最初のコントロール "m ="行オファーで "new"の値を持っている必要があります。クライアントからMRCPサーバーへの後続の "m ="行の提供には、クライアントが新しい接続をセットアップするか、既存の接続を共有するかによって、それぞれ「新規」または「既存」が含まれる場合があります。クライアントが「new」の値を指定する場合、サーバーは「new」の値で応答する必要があります。クライアントが「既存」の値を指定する場合、サーバーは応答する必要があります。応答の正当な値は、サーバーが既存の接続の共有を希望する場合は「既存」、そうでない場合は「新規」です。後者の場合、クライアントは新しいトランスポート接続を開始する必要があります。
When the client wants to deallocate the resource from this session, it issues a new SDP offer, according to RFC 3264 [RFC3264], where the control "m=" line port MUST be set to 0. This SDP offer is sent in a SIP re-INVITE request. This deallocates the associated MRCPv2 identifier and resource. The server MUST NOT close the TCP or TLS connection if it is currently being shared among multiple MRCP channels. When all MRCP channels that may be sharing the connection are released and/or the associated SIP dialog is terminated, the client or server terminates the connection.
クライアントがこのセッションからリソースの割り当てを解除する場合、RFC 3264 [RFC3264]に従って、新しいSDPオファーを発行します。ここで、コントロール "m ="ラインポートは0に設定する必要があります。このSDPオファーはSIPで送信されますre-INVITEリクエスト。これにより、関連するMRCPv2識別子とリソースの割り当てが解除されます。現在複数のMRCPチャネル間で共有されている場合、サーバーはTCPまたはTLS接続を閉じてはなりません（MUST NOT）。接続を共有している可能性のあるすべてのMRCPチャネルが解放されるか、関連するSIPダイアログが終了すると、クライアントまたはサーバーが接続を終了します。
When the client wants to tear down the whole session and all its resources, it MUST issue a SIP BYE request to close the SIP session. This will deallocate all the control channels and resources allocated under the session.
クライアントがセッション全体とそのすべてのリソースを破棄する場合は、SIP BYE要求を発行してSIPセッションを閉じる必要があります。これにより、セッションで割り当てられたすべての制御チャネルとリソースの割り当てが解除されます。
All servers MUST support TLS. Servers MAY use TCP without TLS in controlled environments (e.g., not in the public Internet) where both nodes are inside a protected perimeter, for example, preventing access to the MRCP server from remote nodes outside the controlled perimeter. It is up to the client, through the SDP offer, to choose which transport it wants to use for an MRCPv2 session. Aside from the exceptions given above, when using TCP, the "m=" lines MUST conform to RFC4145 [RFC4145], which describes the usage of SDP for connection-oriented transport. When using TLS, the SDP "m=" line for the control stream MUST conform to Connection-Oriented Media (COMEDIA) over TLS [RFC4572], which specifies the usage of SDP for establishing a secure connection-oriented transport over TLS.
すべてのサーバーはTLSをサポートする必要があります。サーバーは、両方のノードが保護された境界の内側にある（たとえば、制御された境界の外側のリモートノードからMRCPサーバーへのアクセスを防ぐ）制御された環境（公共のインターネットではないなど）でTLSなしのTCPを使用できます（MAY）。 MRDPv2セッションに使用するトランスポートを選択するかどうかは、SDPオファーを通じてクライアントに委ねられています。上記の例外を除いて、TCPを使用する場合、「m =」行は、コネクション型トランスポートのSDPの使用法を説明するRFC4145 [RFC4145]に準拠する必要があります。 TLSを使用する場合、制御ストリームのSDP "m ="行はTLS [RFC4572]上の接続指向メディア（COMEDIA）に準拠する必要があります。これは、TLSを介した安全な接続指向のトランスポートを確立するためのSDPの使用を指定します。
This first example shows the power of using SIP to route to the appropriate resource. In the example, note the use of a request to a domain's speech server service in the INVITE to mresources@example.com. The SIP routing machinery in the domain locates the actual server, mresources@server.example.com, which gets returned in the 200 OK. Note that "cmid" is defined in Section 4.4.
この最初の例は、SIPを使用して適切なリソースにルーティングする能力を示しています。この例では、mresources @ example.comへのINVITEにあるドメインの音声サーバーサービスへのリクエストの使用に注意してください。ドメイン内のSIPルーティング機構は、実際のサーバーmresources@server.example.comを見つけ、200 OKで返されます。 「cmid」はセクション4.4で定義されていることに注意してください。
This example exchange adds a resource control channel for a synthesizer. Since a synthesizer also generates an audio stream, this interaction also creates a receive-only Real-Time Protocol (RTP) [RFC3550] media session for the server to send audio to. The SIP dialog with the media source/sink is independent of MRCP and is not shown.
この例の交換では、シンセサイザのリソース制御チャネルを追加します。シンセサイザはオーディオストリームも生成するため、このやり取りにより、サーバーがオーディオを送信するための受信専用リアルタイムプロトコル（RTP）[RFC3550]メディアセッションも作成されます。メディアソース/シンクのSIPダイアログはMRCPから独立しているため、表示されません。
C->S: INVITE sip:mresources@example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf1 Max-Forwards:6 To:MediaServer <sip:mresources@example.com> From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314161 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:...
C-> S：INVITE sip：mresources@example.com SIP / 2.0 Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf1 Max-Forwards：6 To：MediaServer <sip：mresources@example.com> From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314161 INVITE Contact：<sip： sarvi@client.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=sarvi 2890844526 2890844526 IN IP4 192.0.2.12
s=-
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:new
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf1;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314161 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf1; received = 192.0.32.10 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314161 INVITE連絡先：<sip：mresources@server.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=- 2890842808 2890842808 IN IP4 192.0.2.11
s=-
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1
a=setup:passive
a=connection:new
a=channel:32AECB234338@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S: ACK sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf2
Max-Forwards:6
To:MediaServer <sip:mresources@example.com>;tag=62784
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314161 ACK
Content-Length:0
Example: Add Synthesizer Control Channel
例：シンセサイザーコントロールチャネルの追加
This example exchange continues from the previous figure and allocates an additional resource control channel for a recognizer. Since a recognizer would need to receive an audio stream for recognition, this interaction also updates the audio stream to sendrecv, making it a two-way RTP media session.
この例の交換は前の図の続きで、認識機能に追加のリソース制御チャネルを割り当てます。レコグナイザは認識のためにオーディオストリームを受信する必要があるため、この対話はオーディオストリームもsendrecvに更新し、双方向のRTPメディアセッションにします。
C->S: INVITE sip:mresources@server.example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf3 Max-Forwards:6 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314162 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:...
C-> S：INVITE sip：mresources@server.example.com SIP / 2.0 Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf3 Max-Forwards：6 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314162 INVITE連絡先：<sip：sarvi@client.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=sarvi 2890844526 2890844527 IN IP4 192.0.2.12
s=-
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=mid:1
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:1
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf3;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314162 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf3; received = 192.0.32.10 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314162 INVITE連絡先：<sip：mresources@server.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=- 2890842808 2890842809 IN IP4 192.0.2.11
s=-
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1
a=setup:passive
a=connection:existing
a=channel:32AECB234338@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendrecv
a=mid:1
m=application 32416 TCP/MRCPv2 1
a=setup:passive
a=connection:existing
a=channel:32AECB234338@speechrecog
a=cmid:1
C->S: ACK sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf4
Max-Forwards:6
To:MediaServer <sip:mresources@example.com>;tag=62784
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314162 ACK
Content-Length:0
Example: Add Recognizer
例：認識機能を追加する
This example exchange continues from the previous figure and deallocates the recognizer channel. Since a recognizer no longer needs to receive an audio stream, this interaction also updates the RTP media session to recvonly.
この例の交換は、前の図から続行され、認識チャネルの割り当てを解除します。レコグナイザがオーディオストリームを受信する必要がなくなったため、この対話はRTPメディアセッションもrecvonlyに更新します。
C->S: INVITE sip:mresources@server.example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf5 Max-Forwards:6 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314163 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:...
C-> S：INVITE sip：mresources@server.example.com SIP / 2.0 Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf5 Max-Forwards：6 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314163 INVITE連絡先：<sip：sarvi@client.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=sarvi 2890844526 2890844528 IN IP4 192.0.2.12
s=-
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=recvonly
a=mid:1
m=application 0 TCP/MRCPv2 1
a=resource:speechrecog
a=cmid:1
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf5;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:314163 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf5; received = 192.0.32.10 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：314163 INVITE連絡先：<sip：mresources@server.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=- 2890842808 2890842810 IN IP4 192.0.2.11
s=-
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1
a=channel:32AECB234338@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
m=application 0 TCP/MRCPv2 1
a=channel:32AECB234338@speechrecog
a=cmid:1
C->S: ACK sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf6
Max-Forwards:6
To:MediaServer <sip:mresources@example.com>;tag=62784
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314163 ACK
Content-Length:0
Example: Deallocate Recognizer
例：Recognizer Recognizer
Since MRCPv2 resources either generate or consume media streams, the client or the server needs to associate media sessions with their corresponding resource or resources. More than one resource could be associated with a single media session or each resource could be assigned a separate media session. Also, note that more than one media session can be associated with a single resource if need be, but this scenario is not useful for the current set of resources. For example, a synthesizer and a recognizer could be associated to the same media session (m=audio line), if it is opened in "sendrecv" mode. Alternatively, the recognizer could have its own "sendonly" audio session, and the synthesizer could have its own "recvonly" audio session.
MRCPv2リソースはメディアストリームを生成または消費するため、クライアントまたはサーバーは、メディアセッションを対応する1つまたは複数のリソースに関連付ける必要があります。複数のリソースを1つのメディアセッションに関連付けることも、各リソースに個別のメディアセッションを割り当てることもできます。また、必要に応じて複数のメディアセッションを1つのリソースに関連付けることができますが、このシナリオは現在のリソースセットには役立ちません。たとえば、シンセサイザとレコグナイザを「sendrecv」モードで開いた場合、同じメディアセッション（m =オーディオライン）に関連付けることができます。あるいは、レコグナイザが独自の「sendonly」オーディオセッションを持ち、シンセサイザが独自の「recvonly」オーディオセッションを持つこともできます。
The association between control channels and their corresponding media sessions is established using a new "resource channel media identifier" media-level attribute ("cmid"). Valid values of this attribute are the values of the "mid" attribute defined in RFC 5888 [RFC5888]. If there is more than one audio "m=" line, then each audio "m=" line MUST have a "mid" attribute. Each control "m=" line MAY have one or more "cmid" attributes that match the resource control channel to the "mid" attributes of the audio "m=" lines it is associated with. Note that if a control "m=" line does not have a "cmid" attribute it will not be associated with any media. The operations on such a resource will hence be limited. For example, if it was a recognizer resource, the RECOGNIZE method requires an associated media to process while the INTERPRET method does not. The formatting of the "cmid" attribute is described by the following ABNF: cmid-attribute = "a=cmid:" identification-tag identification-tag = token
コントロールチャネルとそれに対応するメディアセッションの間の関連付けは、新しい「リソースチャネルメディア識別子」メディアレベル属性（「cmid」）を使用して確立されます。この属性の有効な値は、RFC 5888 [RFC5888]で定義されている「mid」属性の値です。複数のオーディオ「m =」行がある場合、各オーディオ「m =」行には「mid」属性が必要です。各コントロール "m ="行は、リソースコントロールチャネルを、関連付けられているオーディオ "m ="行の "mid"属性に一致させる1つ以上の "cmid"属性を持つことができます（MAY）。コントロール「m =」行に「cmid」属性がない場合は、どのメディアにも関連付けられないことに注意してください。したがって、そのようなリソースでの操作は制限されます。たとえば、それが認識リソースであった場合、RECOGNIZEメソッドは関連メディアを処理する必要がありますが、INTERPRETメソッドは処理しません。 「cmid」属性のフォーマットは、次のABNFによって記述されます。cmid-attribute = "a = cmid："識別タグ識別タグ=トークン
To allow this flexible mapping of media sessions to MRCPv2 control channels, a single audio "m=" line can be associated with multiple resources, or each resource can have its own audio "m=" line. For example, if the client wants to allocate a recognizer and a synthesizer and associate them with a single two-way audio stream, the SDP offer would contain two control "m=" lines and a single audio "m=" line with an attribute of "sendrecv". Each of the control "m=" lines would have a "cmid" attribute whose value matches the "mid" of the audio "m=" line. If, on the other hand, the client wants to allocate a recognizer and a synthesizer each with its own separate audio stream, the SDP offer would carry two control "m=" lines (one for the recognizer and another for the synthesizer) and two audio "m=" lines (one with the attribute "sendonly" and another with attribute "recvonly"). The "cmid" attribute of the recognizer control "m=" line would match the "mid" value of the "sendonly" audio "m=" line, and the "cmid" attribute of the synthesizer control "m=" line would match the "mid" attribute of the "recvonly" "m=" line.
メディアセッションからMRCPv2制御チャネルへのこの柔軟なマッピングを可能にするために、単一のオーディオ "m ="行を複数のリソースに関連付けるか、各リソースに独自のオーディオ "m ="行を含めることができます。たとえば、クライアントがレコグナイザとシンセサイザを割り当てて、それらを単一の双方向オーディオストリームに関連付ける場合、SDPオファーには、2つのコントロール「m =」行と属性を持つ1つのオーディオ「m =」行が含まれます。 「sendrecv」の。各コントロール「m =」行には「cmid」属性があり、その値はオーディオ「m =」行の「mid」と一致します。一方、クライアントがそれぞれ独自のオーディオストリームを備えた認識エンジンとシンセサイザを割り当てる場合、SDPオファーは2つの制御 "m ="行（1つは認識エンジン用、もう1つはシンセサイザ用）と2つを実行します。オーディオ "m ="行（1つは属性 "sendonly"、もう1つは属性 "recvonly"）。認識機能コントロール「m =」行の「cmid」属性は、「sendonly」オーディオ「m =」行の「mid」値と一致し、シンセサイザコントロール「m =」行の「cmid」属性は一致します「recvonly」「m =」行の「mid」属性。
When a server receives media (e.g., audio) on a media session that is associated with more than one media processing resource, it is the responsibility of the server to receive and fork the media to the resources that need to consume it. If multiple resources in an MRCPv2 session are generating audio (or other media) to be sent on a single associated media session, it is the responsibility of the server either to multiplex the multiple streams onto the single RTP session or to contain an embedded RTP mixer (see RFC 3550 [RFC3550]) to combine the multiple streams into one. In the former case, the media stream will contain RTP packets generated by different sources, and hence the packets will have different Synchronization Source Identifiers (SSRCs). In the latter case, the RTP packets will contain multiple Contributing Source Identifiers (CSRCs) corresponding to the original streams before being combined by the mixer. If an MRCPv2 server implementation neither multiplexes nor mixes, it MUST disallow the client from associating multiple such resources to a single audio stream by rejecting the SDP offer with a SIP 488 "Not Acceptable" error. Note that there is a large installed base that will return a SIP 501 "Not Implemented" error in this case. To facilitate interoperability with this installed base, new implementations SHOULD treat a 501 in this context as a 488 when it is received from an element known to be a legacy implementation.
サーバーが複数のメディア処理リソースに関連付けられているメディアセッションでメディア（オーディオなど）を受信する場合、メディアを受信して、それを消費する必要があるリソースにフォークするのはサーバーの責任です。 MRCPv2セッションの複数のリソースがオーディオ（または他のメディア）を生成して、関連付けられた単一のメディアセッションで送信する場合、サーバーは、複数のストリームを単一のRTPセッションに多重化するか、組み込みのRTPミキサーを含める必要があります。 （RFC 3550 [RFC3550]を参照）複数のストリームを1つに結合します。前者の場合、メディアストリームにはさまざまなソースによって生成されたRTPパケットが含まれるため、パケットにはさまざまな同期ソース識別子（SSRC）が含まれます。後者の場合、RTPパケットには、ミキサーで結合される前の元のストリームに対応する複数のソース識別子（CSRC）が含まれます。 MRCPv2サーバーの実装が多重化も混合もしない場合、SIPオファーをSIP 488「Not Acceptable」エラーで拒否することにより、クライアントがそのような複数のリソースを単一のオーディオストリームに関連付けることを禁止する必要があります。この場合、SIP 501 "Not Implemented"エラーを返す大きなインストールベースがあることに注意してください。このインストールベースとの相互運用性を促進するために、新しい実装は、レガシー実装であることがわかっている要素から受け取ったときに、このコンテキストの501を488として扱う必要があります。
The MRCPv2 messages defined in this document are transported over a TCP or TLS connection between the client and the server. The method for setting up this transport connection and the resource control channel is discussed in Sections 4.1 and 4.2. Multiple resource control channels between a client and a server that belong to different SIP dialogs can share one or more TLS or TCP connections between them; the server and client MUST support this mode of operation. Clients and servers MUST use the MRCPv2 channel identifier, carried in the Channel-Identifier header field in individual MRCPv2 messages, to differentiate MRCPv2 messages from different resource channels (see Section 6.2.1 for details). All MRCPv2 servers MUST support TLS. Servers MAY use TCP without TLS in controlled environments (e.g., not in the public Internet) where both nodes are inside a protected perimeter, for example, preventing access to the MRCP server from remote nodes outside the controlled perimeter. It is up to the client to choose which mode of transport it wants to use for an MRCPv2 session.
このドキュメントで定義されているMRCPv2メッセージは、クライアントとサーバー間のTCPまたはTLS接続を介して転送されます。このトランスポート接続とリソース制御チャネルを設定する方法については、セクション4.1と4.2で説明します。異なるSIPダイアログに属するクライアントとサーバー間の複数のリソース制御チャネルは、それらの間の1つ以上のTLSまたはTCP接続を共有できます。サーバーとクライアントは、この操作モードをサポートする必要があります。クライアントとサーバーは、個々のMRCPv2メッセージのChannel-Identifierヘッダーフィールドに含まれるMRCPv2チャネル識別子を使用して、異なるリソースチャネルからMRCPv2メッセージを区別する必要があります（詳細については、セクション6.2.1を参照）。すべてのMRCPv2サーバーはTLSをサポートする必要があります。サーバーは、両方のノードが保護された境界の内側にある（たとえば、制御された境界の外側のリモートノードからのMRCPサーバーへのアクセスを防ぐ）制御された環境（公共のインターネットではないなど）でTLSなしのTCPを使用できます（MAY）。 MRCPv2セッションで使用するトランスポートモードを選択するかどうかは、クライアントの責任です。
Most examples from here on show only the MRCPv2 messages and do not show the SIP messages that may have been used to establish the MRCPv2 control channel.
これ以降のほとんどの例では、MRCPv2メッセージのみを示し、MRCPv2制御チャネルの確立に使用された可能性のあるSIPメッセージは示していません。
If an MRCP client notices that the underlying connection has been closed for one of its MRCP channels, and it has not previously initiated a re-INVITE to close that channel, it MUST send a BYE to close down the SIP dialog and all other MRCP channels. If an MRCP server notices that the underlying connection has been closed for one of its MRCP channels, and it has not previously received and accepted a re-INVITE closing that channel, then it MUST send a BYE to close down the SIP dialog and all other MRCP channels.
MRCPクライアントが、そのMRCPチャネルの1つで基になる接続が閉じられたことに気づき、以前にそのチャネルを閉じるためのre-INVITEを開始していない場合、BYEを送信してSIPダイアログと他のすべてのMRCPチャネルを閉じる必要があります。 。 MRCPサーバーが、そのMRCPチャネルの1つで基礎となる接続が閉じられたことに気づき、そのチャネルを閉じるre-INVITEを以前に受信および受け入れていない場合、BYEを送信してSIPダイアログおよびその他すべてを閉じる必要があります。 MRCPチャネル。
Except as otherwise indicated, MRCPv2 messages are Unicode encoded in UTF-8 (RFC 3629 [RFC3629]) to allow many different languages to be represented. DEFINE-GRAMMAR (Section 9.8), for example, is one such exception, since its body can contain arbitrary XML in arbitrary (but specified via XML) encodings. MRCPv2 also allows message bodies to be represented in other character sets (for example, ISO 8859-1 [ISO.8859-1.1987]) because, in some locales, other character sets are already in widespread use. The MRCPv2 headers (the first line of an MRCP message) and header field names use only the US-ASCII subset of UTF-8.
特に明記されていない限り、MRCPv2メッセージはUTF-8（RFC 3629 [RFC3629]）でエンコードされたUnicodeであり、さまざまな言語を表現できます。たとえば、DEFINE-GRAMMAR（セクション9.8）はそのような例外の1つです。その本体には、任意の（ただしXMLで指定された）エンコーディングの任意のXMLを含めることができるためです。一部のロケールでは、他の文字セットがすでに広く使用されているため、MRCPv2では、メッセージ本文を他の文字セット（ISO 8859-1 [ISO.8859-1.1987]など）で表すこともできます。 MRCPv2ヘッダー（MRCPメッセージの最初の行）とヘッダーフィールド名は、UTF-8のUS-ASCIIサブセットのみを使用します。
Lines are terminated by CRLF (carriage return, then line feed). Also, some parameters in the message 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（復帰、次に改行）で終了します。また、メッセージの一部のパラメータには、バイナリデータまたは複数行にわたるレコードが含まれる場合があります。このようなフィールドには、パラメーターに関連付けられた長さの値があり、パラメーターの直後のオクテット数を示します。
The MRCPv2 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, an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and an optional message body.
MRCPv2メッセージセットは、クライアントからサーバーへの要求、サーバーからクライアントへの応答、およびサーバーからクライアントへの非同期イベントで構成されます。これらすべてのメッセージは、開始行、1つ以上のヘッダーフィールド、ヘッダーフィールドの終わりを示す空の行（CRLFの前に何もない行）、およびオプションのメッセージ本文で構成されます。
generic-message = start-line message-header CRLF [ message-body ]
generic-message = start-line message-header CRLF [message-body]
message-body = *OCTET
start-line = request-line / response-line / event-line
message-header = 1*(generic-header / resource-header / generic-field)
resource-header = synthesizer-header
/ recognizer-header
/ recorder-header
/ verifier-header
The message-body contains resource-specific and message-specific data. The actual media types used to carry the data are specified in the sections defining the individual messages. Generic header fields are described in Section 6.2.
メッセージ本文には、リソース固有のデータとメッセージ固有のデータが含まれます。データの伝送に使用される実際のメディアタイプは、個々のメッセージを定義するセクションで指定されています。汎用ヘッダーフィールドについては、セクション6.2で説明します。
If a message contains a message body, the message MUST contain content-headers indicating the media type and encoding of the data in the message body.
メッセージにメッセージ本文が含まれている場合、メッセージには、メッセージ本文のデータのメディアタイプとエンコーディングを示すコンテンツヘッダーが含まれている必要があります。
Request, response and event messages (described in following sections) include the version of MRCP that the message conforms to. Version compatibility rules follow [H3.1] regarding version ordering, compliance requirements, and upgrading of version numbers. The version information is indicated by "MRCP" (as opposed to "HTTP" in [H3.1]) or "MRCP/2.0" (as opposed to "HTTP/1.1" in [H3.1]). To be compliant with this specification, clients and servers sending MRCPv2 messages MUST indicate an mrcp-version of "MRCP/2.0". ABNF productions using mrcp-version can be found in Sections 5.2, 5.3, and 5.5.
要求、応答、およびイベントメッセージ（次のセクションで説明）には、メッセージが準拠するMRCPのバージョンが含まれています。バージョンの互換性ルールは、バージョンの順序、コンプライアンス要件、およびバージョン番号のアップグレードに関して[H3.1]に従います。バージョン情報は、[MRCP]（[H3.1]の[HTTP]ではなく）または[MRCP / 2.0]（[H3.1]の[HTTP / 1.1]とは反対）で示されます。この仕様に準拠するには、MRCPv2メッセージを送信するクライアントとサーバーは、「MRCP / 2.0」のmrcp-versionを示す必要があります。 mrcp-versionを使用したABNF製品は、セクション5.2、5.3、および5.5にあります。
mrcp-version = "MRCP" "/" 1*2DIGIT "." 1*2DIGIT
The message-length field specifies the length of the message in octets, including the start-line, and MUST be the second token from the beginning of the message. This is to make the framing and parsing of the message simpler to do. This field specifies the length of the message including data that may be encoded into the body of the message. Note that this value MAY be given as a fixed-length integer that is zero-padded (with leading zeros) in order to eliminate or reduce inefficiency in cases where the message-length value would change as a result of the length of the message-length token itself. This value, as with all lengths in MRCP, is to be interpreted as a base-10 number. In particular, leading zeros do not indicate that the value is to be interpreted as a base-8 number.
メッセージ長フィールドは、メッセージの長さをオクテットで指定します（開始行を含む）。メッセージの先頭から2番目のトークンでなければなりません。これは、メッセージのフレーミングと解析をより簡単にするためです。このフィールドは、メッセージの本文にエンコードされるデータを含むメッセージの長さを指定します。この値は、メッセージの長さの結果としてメッセージの長さの値が変化する場合の非効率性を排除または低減するために、ゼロでパディングされた（先行ゼロで）固定長の整数として指定できることに注意してください。長さトークン自体。この値は、MRCPのすべての長さと同様に、10を底とする数値として解釈されます。特に、先行ゼロは、値が8進数として解釈されることを示していません。
message-length = 1*19DIGIT
The following sample MRCP exchange demonstrates proper message-length values. The values for message-length have been removed from all other examples in the specification and replaced by '...' to reduce confusion in the case of minor message-length computation errors in those examples.
次のサンプルMRCP交換は、適切なメッセージ長の値を示しています。メッセージ長の値は、仕様の他のすべての例から削除され、「...」に置き換えられました。これらの例での小さなメッセージ長の計算エラーの場合の混乱を減らすためです。
C->S: MRCP/2.0 877 INTERPRET 543266
Channel-Identifier:32AECB23433801@speechrecog
Interpret-Text:may I speak to Andre Roy
Content-Type:application/srgs+xml
Content-ID:<request1@form-level.store>
Content-Length:661
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 82 543266 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 634 INTERPRETATION-COMPLETE 543266 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
Completion-Cause:000 success
Content-Type:application/nlsml+xml
Content-Length:441
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
All MRCPv2 messages, responses and events MUST carry the Channel-Identifier header field so the server or client can differentiate messages from different control channels that may share the same transport connection.
すべてのMRCPv2メッセージ、応答、およびイベントは、サーバーまたはクライアントが同じトランスポート接続を共有する可能性のある異なる制御チャネルからのメッセージを区別できるように、チャネル識別子ヘッダーフィールドを運ぶ必要があります。
In the resource-specific header field descriptions in Sections 8-11, a header field is disallowed on a method (request, response, or event) for that resource unless specifically listed as being allowed. Also, the phrasing "This header field MAY occur on method X" indicates that the header field is allowed on that method but is not required to be used in every instance of that method.
セクション8〜11のリソース固有のヘッダーフィールドの説明では、特に許可されていない限り、そのリソースのメソッド（要求、応答、またはイベント）でヘッダーフィールドは許可されていません。また、「このヘッダーフィールドはメソッドXで発生する可能性があります」という表現は、ヘッダーフィールドがそのメソッドで許可されているが、そのメソッドのすべてのインスタンスで使用する必要がないことを示しています。
An MRCPv2 request consists of a Request line followed by the message header section and an optional message body containing data specific to the request message.
MRCPv2要求は、要求行と、それに続くメッセージヘッダーセクション、および要求メッセージに固有のデータを含むオプションのメッセージ本文で構成されます。
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 the protocol in use.
クライアントからサーバーへの要求メッセージには、最初の行に適用されるメソッド、その要求のメソッドタグ、および使用中のプロトコルのバージョンが含まれています。
request-line = mrcp-version SP message-length SP method-name SP request-id CRLF
request-line = mrcp-version SPメッセージ長SPメソッド名SPリクエストID CRLF
The mrcp-version field is the MRCP protocol version that is being used by the client.
mrcp-versionフィールドは、クライアントが使用しているMRCPプロトコルのバージョンです。
The message-length field specifies the length of the message, including the start-line.
message-lengthフィールドは、開始行を含むメッセージの長さを指定します。
Details about the mrcp-version and message-length fields are given in Section 5.1.
mrcp-versionおよびmessage-lengthフィールドの詳細は、セクション5.1で説明されています。
The method-name field identifies the specific request that the client is making to the server. Each resource supports a subset of the MRCPv2 methods. The subset for each resource is defined in the section of the specification for the corresponding resource.
method-nameフィールドは、クライアントがサーバーに対して行っている特定の要求を識別します。各リソースは、MRCPv2メソッドのサブセットをサポートしています。各リソースのサブセットは、対応するリソースの仕様のセクションで定義されています。
method-name = generic-method
/ synthesizer-method
/ recognizer-method
/ recorder-method
/ verifier-method
The request-id field is a unique identifier representable as an unsigned 32-bit integer created by the client and sent to the server. Clients MUST utilize monotonically increasing request-ids for consecutive requests within an MRCP session. The request-id space is linear (i.e., not mod(32)), so the space does not wrap, and validity can be checked with a simple unsigned comparison operation. The client may choose any initial value for its first request, but a small integer is RECOMMENDED to avoid exhausting the space in long sessions. If the server receives duplicate or out-of-order requests, the server MUST reject the request with a response code of 410. Since request-ids are scoped to the MRCP session, they are unique across all TCP connections and all resource channels in the session.
request-idフィールドは、クライアントによって作成され、サーバーに送信される符号なし32ビット整数として表現可能な一意の識別子です。クライアントは、MRCPセッション内の連続したリクエストに対して、単調に増加するリクエストIDを利用する必要があります。 request-idスペースは線形（つまり、mod（32）ではない）であるため、スペースは折り返されず、単純な符号なし比較演算で有効性を確認できます。クライアントは最初のリクエストに任意の初期値を選択できますが、長いセッションでスペースが使い果たされるのを避けるために、小さな整数を使用することをお勧めします。サーバーが重複または順序が狂った要求を受信した場合、サーバーは応答コード410で要求を拒否する必要があります。要求IDはMRCPセッションにスコープが設定されているため、すべてのTCP接続とすべてのリソースチャネルで一意です。セッション。
The server resource MUST use the client-assigned identifier in its response to the request. If the request does not complete synchronously, future asynchronous events associated with this request MUST carry the client-assigned request-id.
サーバーリソースは、要求への応答でクライアントが割り当てた識別子を使用する必要があります。リクエストが同期的に完了しない場合、このリクエストに関連付けられた将来の非同期イベントは、クライアントが割り当てたリクエストIDを伝える必要があります。
request-id = 1*10DIGIT
After receiving and interpreting the request message for a method, the server resource responds with an MRCPv2 response message. The response consists of a response line followed by the message header section and an optional message body containing data specific to the method.
メソッドの要求メッセージを受信して解釈した後、サーバーリソースはMRCPv2応答メッセージで応答します。応答は、応答行と、それに続くメッセージヘッダーセクション、およびメソッド固有のデータを含むオプションのメッセージ本文で構成されます。
response-line = mrcp-version SP message-length SP request-id SP status-code SP request-state CRLF
response-line = mrcp-version SPメッセージ長SP要求ID SPステータスコードSP要求状態CRLF
The mrcp-version field MUST contain the version of the request if supported; otherwise, it MUST contain the highest version of MRCP supported by the server.
サポートされている場合、mrcp-versionフィールドには要求のバージョンを含める必要があります。それ以外の場合は、サーバーでサポートされている最新バージョンのMRCPを含める必要があります。
The message-length field specifies the length of the message, including the start-line.
message-lengthフィールドは、開始行を含むメッセージの長さを指定します。
Details about the mrcp-version and message-length fields are given in Section 5.1.
mrcp-versionおよびmessage-lengthフィールドの詳細は、セクション5.1で説明されています。
The request-id used in the response MUST match the one sent in the corresponding request message.
応答で使用されるrequest-idは、対応する要求メッセージで送信されたものと一致する必要があります。
The status-code field is a 3-digit code representing the success or failure or other status of the request.
ステータスコードフィールドは、リクエストの成功または失敗、またはその他のステータスを表す3桁のコードです。
status-code = 3DIGIT
The request-state field indicates if the action 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 or other messages from that resource to the client with that request-id. The PENDING status means that the request has been placed in 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 may be delivered with that request-id.
request-stateフィールドは、要求によって開始されたアクションがPENDING、IN-PROGRESS、またはCOMPLETEのいずれであるかを示します。 COMPLETEステータスは、リクエストが完了まで処理され、そのリソースからそのリクエストIDを持つクライアントへのイベントや他のメッセージがなくなることを意味します。 PENDINGステータスは、リクエストがキューに入れられ、先入れ先出しの順序で処理されることを意味します。 IN-PROGRESSステータスは、リクエストが処理中で、まだ完了していないことを意味します。 PENDINGまたはIN-PROGRESSステータスは、そのリクエストIDでさらにイベントメッセージが配信される可能性があることを示します。
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
The status codes are classified under the Success (2xx), Client Failure (4xx), and Server Failure (5xx) codes.
ステータスコードは、成功（2xx）、クライアント障害（4xx）、サーバー障害（5xx）コードに分類されます。
+------------+--------------------------------------------------+
| Code | Meaning |
+------------+--------------------------------------------------+
| 200 | Success |
| 201 | Success with some optional header fields ignored |
+------------+--------------------------------------------------+
Success (2xx)
成功（2xx）
+--------+----------------------------------------------------------+
| Code | Meaning |
+--------+----------------------------------------------------------+
| 401 | Method not allowed |
| 402 | Method not valid in this state |
| 403 | Unsupported header field |
| 404 | Illegal value for header field. This is the error for a |
| | syntax violation. |
| 405 | Resource not allocated for this session or does not |
| | exist |
| 406 | Mandatory Header Field Missing |
| 407 | Method or Operation Failed (e.g., Grammar compilation |
| | failed in the recognizer. Detailed cause codes might be |
| | available through a resource-specific header.) |
| 408 | Unrecognized or unsupported message entity |
| 409 | Unsupported Header Field Value. This is a value that is |
| | syntactically legal but exceeds the implementation's |
| | capabilities or expectations. |
| 410 | Non-Monotonic or Out-of-order sequence number in request.|
| 411-420| Reserved for future assignment |
+--------+----------------------------------------------------------+
Client Failure (4xx)
クライアント障害（4xx）
+------------+--------------------------------+
| Code | Meaning |
+------------+--------------------------------+
| 501 | Server Internal Error |
| 502 | Protocol Version not supported |
| 503 | Reserved for future assignment |
| 504 | Message too large |
+------------+--------------------------------+
Server Failure (5xx)
サーバー障害（5xx）
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. The event message consists of an event header line followed by the message header section and an optional message body containing data specific to the event message. The header line has the request-id of the corresponding request and status value. The request-state value is COMPLETE if the request is done and this was the last event, else it is IN-PROGRESS.
サーバーリソースは、状態の変化や特定のイベントの発生をクライアントに通知する必要がある場合があります。これらのメッセージは、要求がすぐには完了せず、応答がPENDINGまたはIN-PROGRESSのステータスを返す場合に使用されます。リクエストの中間結果とイベントは、サーバーからのイベントメッセージを通じてクライアントに示されます。イベントメッセージは、イベントヘッダー行とそれに続くメッセージヘッダーセクション、およびイベントメッセージに固有のデータを含むオプションのメッセージ本文で構成されます。ヘッダー行には、対応するリクエストのリクエストIDとステータス値があります。要求が完了し、これが最後のイベントであった場合、request-state値はCOMPLETEです。それ以外の場合は、IN-PROGRESSです。
event-line = mrcp-version SP message-length SP event-name SP request-id SP request-state CRLF
event-line = mrcp-version SP message-length SP event-name SP request-id SP request-state CRLF
The mrcp-version used here is identical to the one used in the Request/Response line and indicates the highest version of MRCP running on the server.
ここで使用されるmrcp-versionは、要求/応答行で使用されるものと同一であり、サーバーで実行されているMRCPの最新バージョンを示します。
The message-length field specifies the length of the message, including the start-line.
message-lengthフィールドは、開始行を含むメッセージの長さを指定します。
Details about the mrcp-version and message-length fields are given in Section 5.1.
mrcp-versionおよびmessage-lengthフィールドの詳細は、セクション5.1で説明されています。
The event-name identifies the nature of the event generated by the media resource. The set of valid event names depends on the resource generating it. See the corresponding resource-specific section of the document.
event-nameは、メディアリソースによって生成されるイベントの性質を識別します。有効なイベント名のセットは、それを生成するリソースによって異なります。ドキュメントの対応するリソース固有のセクションを参照してください。
event-name = synthesizer-event
/ recognizer-event
/ recorder-event
/ verifier-event
The request-id used in the event MUST match the one sent in the request that caused this event.
イベントで使用されるリクエストIDは、このイベントの原因となったリクエストで送信されたものと一致する必要があります。
The request-state indicates whether the Request/Command causing this event is complete or still in progress and whether it is the same as the one mentioned in Section 5.3. The final event for a request has a COMPLETE status indicating the completion of the request.
request-stateは、このイベントの原因となったリクエスト/コマンドが完了しているか、進行中であるか、およびセクション5.3で述べたものと同じかどうかを示します。リクエストの最後のイベントには、リクエストの完了を示すCOMPLETEステータスがあります。
MRCPv2 supports a set of methods and header fields that are common to all resources. These are discussed here; resource-specific methods and header fields are discussed in the corresponding resource-specific section of the document.
MRCPv2は、すべてのリソースに共通のメソッドとヘッダーフィールドのセットをサポートしています。これらについては、ここで説明します。リソース固有のメソッドとヘッダーフィールドについては、ドキュメントの対応するリソース固有のセクションで説明します。
MRCPv2 supports two generic methods for reading and writing the state associated with a resource.
MRCPv2は、リソースに関連付けられた状態を読み書きするための2つの汎用メソッドをサポートしています。
generic-method = "SET-PARAMS" / "GET-PARAMS"
generic-method = "SET-PARAMS" / "GET-PARAMS"
These are described in the following subsections.
これらについては、次のサブセクションで説明します。
The SET-PARAMS method, from the client to the server, tells the MRCPv2 resource to define parameters for the session, such as voice characteristics and prosody on synthesizers, recognition timers on recognizers, etc. If the server accepts and sets all parameters, it MUST return a response status-code of 200. If it chooses to ignore some optional header fields that can be safely ignored without affecting operation of the server, it MUST return 201.
クライアントからサーバーへのSET-PARAMSメソッドは、MRCPv2リソースに、シンセサイザーの音声特性や韻律、認識機能の認識タイマーなどのセッションのパラメーターを定義するように指示します。サーバーがすべてのパラメーターを受け入れて設定した場合、 200の応答ステータスコードを返す必要があります。サーバーの動作に影響を与えずに安全に無視できるオプションのヘッダーフィールドを無視する場合は、201を返す必要があります。
If one or more of the header fields being sent is incorrect, error 403, 404, or 409 MUST be returned as follows:
送信される1つ以上のヘッダーフィールドが正しくない場合、次のようにエラー403、404、または409を返す必要があります。
o If one or more of the header fields being set has an illegal value, the server MUST reject the request with a 404 Illegal Value for Header Field.
o 設定されている1つ以上のヘッダーフィールドに無効な値が含まれている場合、サーバーは、ヘッダーフィールドの404 Illegal Valueでリクエストを拒否する必要があります。
o If one or more of the header fields being set is unsupported for the resource, the server MUST reject the request with a 403 Unsupported Header Field, except as described in the next paragraph.
o 設定されている1つ以上のヘッダーフィールドがリソースでサポートされていない場合、サーバーは、次の段落で説明されている場合を除き、403 Unsupported Header Fieldで要求を拒否する必要があります。
o If one or more of the header fields being set has an unsupported value, the server MUST reject the request with a 409 Unsupported Header Field Value, except as described in the next paragraph.
o 設定されている1つ以上のヘッダーフィールドにサポートされていない値がある場合、サーバーは、次の段落で説明されている場合を除き、409 Unsupported Header Field Valueで要求を拒否する必要があります。
If both error 404 and another error have occurred, only error 404 MUST be returned. If both errors 403 and 409 have occurred, but not error 404, only error 403 MUST be returned.
エラー404と別のエラーの両方が発生した場合は、エラー404のみを返す必要があります。エラー403と409の両方が発生し、エラー404が発生していない場合は、エラー403のみを返す必要があります。
If error 403, 404, or 409 is returned, the response MUST include the bad or unsupported header fields and their values exactly as they were sent from the client. Session parameters modified using SET-PARAMS do not override parameters explicitly specified on individual requests or requests that are IN-PROGRESS.
エラー403、404、または409が返された場合、クライアントから送信されたとおりの不良またはサポートされていないヘッダーフィールドとその値を応答に含める必要があります。 SET-PARAMSを使用して変更されたセッションパラメータは、個々のリクエストまたはIN-PROGRESSであるリクエストで明示的に指定されたパラメータをオーバーライドしません。
C->S: MRCP/2.0 ... SET-PARAMS 543256
Channel-Identifier:32AECB23433802@speechsynth
Voice-gender:female
Voice-variant:3
S->C: MRCP/2.0 ... 543256 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
The GET-PARAMS method, from the client to the server, asks the MRCPv2 resource for its current session parameters, such as voice characteristics and prosody on synthesizers, recognition timers on recognizers, etc. For every header field the client sends in the request without a value, the server MUST include the header field and its corresponding value in the response. If no parameter header fields are specified by the client, then the server MUST return all the settable parameters and their values in the corresponding header section of the response, including vendor-specific parameters. Such wildcard parameter requests can be very processing-intensive, since the number of settable parameters can be large depending on the implementation. Hence, it is RECOMMENDED that the client not use the wildcard GET-PARAMS operation very often. Note that GET-PARAMS returns header field values that apply to the whole session and not values that have a request-level scope. For example, Input-Waveform-URI is a request-level header field and thus would not be returned by GET-PARAMS.
クライアントからサーバーへのGET-PARAMSメソッドは、MRCPv2リソースに、シンセサイザの音声特性や韻律、認識エンジンの認識タイマーなどの現在のセッションパラメータを要求します。クライアントがリクエストで送信するヘッダーフィールドごとに、値の場合、サーバーはヘッダーフィールドとそれに対応する値を応答に含める必要があります。クライアントによってパラメーターヘッダーフィールドが指定されていない場合、サーバーは、ベンダー固有のパラメーターを含む、応答の対応するヘッダーセクションで設定可能なすべてのパラメーターとその値を返す必要があります。実装によっては設定可能なパラメーターの数が多くなる可能性があるため、このようなワイルドカードパラメーター要求は非常に処理集約型になる可能性があります。したがって、クライアントでワイルドカードGET-PARAMS操作を頻繁に使用しないことをお勧めします。 GET-PARAMSは、リクエストレベルのスコープを持つ値ではなく、セッション全体に適用されるヘッダーフィールド値を返すことに注意してください。たとえば、Input-Waveform-URIは要求レベルのヘッダーフィールドであるため、GET-PARAMSでは返されません。
If all of the header fields requested are supported, the server MUST return a response status-code of 200. If some of the header fields being retrieved are unsupported for the resource, the server MUST reject the request with a 403 Unsupported Header Field. Such a response MUST include the unsupported header fields exactly as they were sent from the client, without values.
要求されたすべてのヘッダーフィールドがサポートされている場合、サーバーは200の応答ステータスコードを返す必要があります。取得されているヘッダーフィールドの一部がリソースでサポートされていない場合、サーバーは403 Unsupported Header Fieldで要求を拒否する必要があります。このような応答には、サポートされていないヘッダーフィールドを、値なしでクライアントから送信されたとおりに含める必要があります。
C->S: MRCP/2.0 ... GET-PARAMS 543256
Channel-Identifier:32AECB23433802@speechsynth
Voice-gender:
Voice-variant:
Vendor-Specific-Parameters:com.example.param1;
com.example.param2
S->C: MRCP/2.0 ... 543256 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Voice-gender:female
Voice-variant:3
Vendor-Specific-Parameters:com.example.param1="Company Name";
com.example.param2="124324234@example.com"
All MRCPv2 header fields, which include both the generic-headers defined in the following subsections and the resource-specific header fields defined later, follow the same generic format as that given in Section 3.1 of RFC 5322 [RFC5322]. Each header field consists of a name followed by a colon (":") and the value. Header field names are case-insensitive. The value MAY be preceded by any amount of LWS (linear white space), though a single SP (space) is preferred. Header fields may extend over multiple lines by preceding each extra line with at least one SP or HT (horizontal tab).
次のサブセクションで定義されているジェネリックヘッダーと後で定義されるリソース固有のヘッダーフィールドの両方を含むすべてのMRCPv2ヘッダーフィールドは、RFC 5322 [RFC5322]のセクション3.1で指定されているものと同じ一般的な形式に従います。各ヘッダーフィールドは、名前とその後に続くコロン（ "："）と値で構成されます。ヘッダーフィールド名では大文字と小文字が区別されません。値の前に任意の量のLWS（線形空白）を付けることができますが、単一のSP（空白）が推奨されます。ヘッダーフィールドは、追加の各行の前に少なくとも1つのSPまたはHT（水平タブ）を付けることにより、複数行にまたがることがあります。
generic-field = field-name ":" [ field-value ]
field-name = token
field-value = *LWS field-content *( CRLF 1*LWS field-content)
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS (i.e., linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value). Such leading or trailing LWS MAY be removed without changing the semantics of the field value. Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.
フィールドコンテンツには、先頭または末尾のLWS（つまり、フィールド値の最初の非空白文字の前、またはフィールド値の最後の非空白文字の後に発生する線形空白）は含まれません。このような先頭または末尾のLWSは、フィールド値のセマンティクスを変更せずに削除できます。フィールドコンテンツ間で発生するすべてのLWSは、フィールド値を解釈したり、メッセージをダウンストリームに転送したりする前に、単一のSPで置き換えることができます。
MRCPv2 servers and clients MUST NOT depend on header field order. It is RECOMMENDED to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields. However, MRCPv2 servers and clients MUST be prepared to process the header fields in any order. The only exception to this rule is when there are multiple header fields with the same name in a message.
MRCPv2サーバーとクライアントは、ヘッダーフィールドの順序に依存してはいけません。最初に一般ヘッダーフィールドを送信し、次にリクエストヘッダーフィールドまたは応答ヘッダーフィールドを送信し、エンティティヘッダーフィールドで終了することをお勧めします。ただし、MRCPv2サーバーとクライアントは、ヘッダーフィールドを任意の順序で処理できるように準備する必要があります。このルールの唯一の例外は、メッセージ内に同じ名前のヘッダーフィールドが複数ある場合です。
Multiple header fields with the same name MAY be present in a message if and only if the entire value for that header field is defined as a comma-separated list [i.e., #(values)].
同じ名前の複数のヘッダーフィールドがメッセージに存在する場合があります。そのヘッダーフィールドの値全体がコンマ区切りのリストとして定義されている場合に限ります（例：＃（values））。
Since vendor-specific parameters may be order-dependent, it MUST be possible to combine multiple header fields of the same name into one "name:value" pair without changing the semantics of the message, by appending each subsequent value to the first, each separated by a comma. The order in which header fields with the same name are received is therefore significant to the interpretation of the combined header field value, and thus an intermediary MUST NOT change the order of these values when a message is forwarded.
ベンダー固有のパラメータは順序に依存する可能性があるため、メッセージのセマンティクスを変更せずに、同じ名前の複数のヘッダーフィールドを1つの「name：value」ペアに結合する必要があります。カンマで区切ります。したがって、同じ名前のヘッダーフィールドが受信される順序は、結合されたヘッダーフィールド値の解釈にとって重要であり、したがって、仲介者はメッセージが転送されるときにこれらの値の順序を変更してはなりません。
generic-header = channel-identifier
/ accept
/ active-request-id-list
/ proxy-sync-id
/ accept-charset
/ content-type
/ content-id
/ content-base
/ content-encoding
/ content-location
/ content-length
/ fetch-timeout
/ cache-control
/ logging-tag
/ set-cookie
/ vendor-specific
All MRCPv2 requests, responses, and events MUST contain the Channel-Identifier header field. The value is allocated by the server when a control channel is added to the session and communicated to the client by the "a=channel" attribute in the SDP answer from the server. The header field value consists of 2 parts separated by the '@' symbol. The first part is an unambiguous string identifying the MRCPv2 session. The second part is a string token that specifies one of the media processing resource types listed in Section 3.1. The unambiguous string (first part) MUST be difficult to guess, unique among the resource instances managed by the server, and common to all resource channels with that server established through a single SIP dialog.
すべてのMRCPv2要求、応答、およびイベントには、Channel-Identifierヘッダーフィールドが含まれている必要があります。この値は、制御チャネルがセッションに追加されるときにサーバーによって割り当てられ、サーバーからのSDP応答の "a = channel"属性によってクライアントに通信されます。ヘッダーフィールドの値は、「@」記号で区切られた2つの部分で構成されます。最初の部分は、MRCPv2セッションを識別する明確な文字列です。 2番目の部分は、セクション3.1にリストされているメディア処理リソースタイプの1つを指定する文字列トークンです。明確な文字列（最初の部分）は推測が難しく、サーバーによって管理されるリソースインスタンス間で一意であり、そのサーバーが単一のSIPダイアログを通じて確立されたすべてのリソースチャネルに共通です。
channel-identifier = "Channel-Identifier" ":" channel-id CRLF
channel-id = 1*alphanum "@" 1*alphanum
The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server MUST assume a default value that is specific to the resource type that is being controlled. This default value can be changed for a resource on a session by sending this header field in a SET-PARAMS method. The current default value of this header field for a resource in a session can be found through a GET-PARAMS method. This header field MAY occur on any request.
Acceptヘッダーフィールドは、[H14.1]で定義された構文に従います。 Acceptヘッダーフィールドが存在しない場合、サーバーは、制御されているリソースタイプに固有のデフォルト値を想定する必要があることを除いて、セマンティクスも同じです。このデフォルト値は、SET-PARAMSメソッドでこのヘッダーフィールドを送信することにより、セッション上のリソースに対して変更できます。セッション内のリソースのこのヘッダーフィールドの現在のデフォルト値は、GET-PARAMSメソッドを使用して確認できます。このヘッダーフィールドは、すべてのリクエストで発生する場合があります。
In a request, this header field indicates the list of request-ids to which the request applies. This is useful when there are multiple requests that are PENDING or IN-PROGRESS and the client wants this request to apply to one or more of these specifically.
リクエストの場合、このヘッダーフィールドは、リクエストが適用されるリクエストIDのリストを示します。これは、PENDINGまたはIN-PROGRESSである複数のリクエストがあり、クライアントがこのリクエストをこれらの1つ以上に具体的に適用することを望む場合に役立ちます。
In a response, this header field returns the list of request-ids that the method modified or affected. There could be one or more requests in a request-state of PENDING or IN-PROGRESS. When a method affecting one or more PENDING or IN-PROGRESS requests is sent from the client to the server, the response MUST contain the list of request-ids that were affected or modified by this command in its header section.
応答では、このヘッダーフィールドは、メソッドが変更または影響したリクエストIDのリストを返します。 request-stateがPENDINGまたはIN-PROGRESSのリクエストが1つ以上ある可能性があります。 1つ以上のPENDINGまたはIN-PROGRESSリクエストに影響を与えるメソッドがクライアントからサーバーに送信された場合、レスポンスのヘッダーセクションに、このコマンドによって影響または変更されたリクエストIDのリストが含まれている必要があります。
The Active-Request-Id-List is only used in requests and responses, not in events.
Active-Request-Id-Listはリクエストとレスポンスでのみ使用され、イベントでは使用されません。
For example, if a STOP request with no Active-Request-Id-List is sent to a synthesizer resource 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. The response to the STOP request contains in the Active-Request-Id-List value the request-ids of all the SPEAK requests that were terminated. After sending the STOP response, the server MUST NOT send any SPEAK-COMPLETE or RECOGNITION-COMPLETE events for the terminated requests.
たとえば、Active-Request-Id-ListのないSTOP要求が、PENDINGまたはIN-PROGRESS状態の1つ以上のSPEAK要求を持つシンセサイザリソースに送信される場合、1つのIN-を含むすべてのSPEAK要求をキャンセルする必要があります。進捗。 STOP要求への応答には、Active-Request-Id-List値に、終了されたすべてのSPEAK要求の要求IDが含まれています。 STOP応答を送信した後、サーバーは、終了した要求に対してSPEAK-COMPLETEイベントまたはRECOGNITION-COMPLETEイベントを送信してはなりません（MUST NOT）。
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
When any server resource generates a "barge-in-able" event, it also generates a unique tag. The tag is sent as this header field's value in an event to the client. The client then acts as an intermediary among the server resources and sends a BARGE-IN-OCCURRED method 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, intermediated by the client, to decide if this event has been processed through a direct interaction of the resources. This header field MAY occur only on events and the BARGE-IN-OCCURRED method. The name of this header field contains the word 'proxy' only for historical reasons and does not imply that a proxy server is involved.
サーバーリソースが「割り込み可能」イベントを生成すると、一意のタグも生成されます。タグは、イベントのこのヘッダーフィールドの値としてクライアントに送信されます。次に、クライアントはサーバーリソース間の仲介者として機能し、サーバーリソースから受信したProxy-Sync-Idを使用して、BARGE-IN-OCCURREDメソッドをシンセサイザサーバーリソースに送信します。レコグナイザとシンセサイザのリソースが同じセッションの一部である場合、それらは連携してより迅速な対話と応答を実現することを選択できます。ここで、Proxy-Sync-Idは、クライアントが仲介してイベントを受信するリソースが、このイベントがリソースの直接の対話を通じて処理されたかどうかを判断するのに役立ちます。このヘッダーフィールドは、イベントとBARGE-IN-OCCURREDメソッドでのみ発生する場合があります。このヘッダーフィールドの名前には、歴史的な理由でのみ「プロキシ」という単語が含まれており、プロキシサーバーが関係していることを意味するものではありません。
proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF
See [H14.2]. This specifies the acceptable character sets 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 Semantic Markup Language (NLSML) results of a RECOGNITION-COMPLETE event. This header field is only used on requests.
[H14.2]を参照してください。これは、この要求に関連付けられた応答またはイベントで返されるエンティティの受け入れ可能な文字セットを指定します。これは、RECOGNITION-COMPLETEイベントの自然言語セマンティックマークアップ言語（NLSML）の結果で使用する文字セットを指定するのに役立ちます。このヘッダーフィールドはリクエストでのみ使用されます。
See [H14.17]. MRCPv2 supports a restricted set of registered media types for content, including speech markup, grammar, and recognition results. The content types applicable to each MRCPv2 resource-type are specified in the corresponding section of the document and are registered in the MIME Media Types registry maintained by IANA. The multipart content type "multipart/mixed" is supported to communicate multiple of the above mentioned contents, in which case the body parts MUST NOT contain any MRCPv2-specific header fields. This header field MAY occur on all messages.
[H14.17]を参照してください。 MRCPv2は、音声マークアップ、文法、認識結果など、コンテンツの登録済みメディアタイプの制限されたセットをサポートしています。各MRCPv2リソースタイプに適用可能なコンテンツタイプは、ドキュメントの対応するセクションで指定され、IANAによって維持されるMIMEメディアタイプレジストリに登録されます。マルチパートコンテンツタイプ「multipart / mixed」は、上記のコンテンツの複数を通信するためにサポートされています。この場合、ボディパーツにMRCPv2固有のヘッダーフィールドを含めることはできません。このヘッダーフィールドは、すべてのメッセージで発生する場合があります。
content-type = "Content-Type" ":" media-type-value CRLF
content-type = "Content-Type" "：" media-type-value CRLF
media-type-value = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
パラメータ=属性 "="値
attribute = token
value = token / quoted-string
This header field contains an ID or name for the content by which it can be referenced. This header field operates according to the specification in RFC 2392 [RFC2392] and is required for content disambiguation in multipart messages. In MRCPv2, whenever the associated content is stored by either the client or the server, it MUST be retrievable using this ID. Such content can be referenced later in a session by addressing it with the 'session' URI scheme described in Section 13.6. This header field MAY occur on all messages.
このヘッダーフィールドには、参照できるコンテンツのIDまたは名前が含まれています。このヘッダーフィールドは、RFC 2392 [RFC2392]の仕様に従って動作し、マルチパートメッセージのコンテンツのあいまいさをなくすために必要です。 MRCPv2では、関連するコンテンツがクライアントまたはサーバーのいずれかによって格納されるときは常に、このIDを使用して取得可能でなければなりません（MUST）。このようなコンテンツは、セクション13.6で説明されている「セッション」URIスキームでアドレス指定することにより、セッションの後半で参照できます。このヘッダーフィールドは、すべてのメッセージで発生する場合があります。
The Content-Base entity-header MAY be used to specify the base URI for resolving relative URIs within the entity.
Content-Baseエンティティヘッダーを使用して、エンティティ内の相対URIを解決するためのベースURIを指定できます。
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 multipart media, which in turn can have multiple entities within it. This header field MAY occur on all messages.
ただし、エンティティボディ内のコンテンツのベースURIは、エンティティボディ内で再定義できることに注意してください。この例として、マルチパートメディアがあり、その中に複数のエンティティを含めることができます。このヘッダーフィールドは、すべてのメッセージで発生する場合があります。
The Content-Encoding entity-header is used as a modifier to the Content-Type. When present, its value indicates what additional content encoding 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. Note that the SIP session can be used to determine accepted encodings (see Section 7). This header field MAY occur on all messages.
Content-Encodingエンティティヘッダーは、Content-Typeの修飾子として使用されます。存在する場合、その値は、エンティティ本体に適用されている追加のコンテンツエンコーディングを示します。したがって、Content-Typeヘッダーフィールドによって参照されるメディアタイプを取得するために適用する必要があるデコードメカニズムを示します。 Content-Encodingは主に、基になるメディアタイプのIDを失うことなくドキュメントを圧縮できるようにするために使用されます。 SIPセッションを使用して、受け入れられたエンコーディングを判別できることに注意してください（セクション7を参照）。このヘッダーフィールドは、すべてのメッセージで発生する場合があります。
content-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
Content codings are defined in [H3.5]. An example of its use is Content-Encoding:gzip
コンテンツコーディングは[H3.5]で定義されています。その使用例はContent-Encoding：gzipです。
If multiple encodings have been applied to an entity, the content encodings MUST be listed in the order in which they were applied.
エンティティに複数のエンコーディングが適用されている場合、コンテンツエンコーディングは、それらが適用された順にリストされている必要があります。
The Content-Location entity-header 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. Refer to [H14.14].
Content-Locationエンティティヘッダーを使用して、要求されたリソースのURIとは別の場所からエンティティにアクセスできる場合、メッセージに含まれるエンティティのリソースの場所を提供できます。 [H14.14]を参照してください。
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. This header field is provided for optimization purposes only. The receiver of this header field MAY assume that the entity being sent is identical to what would have been retrieved or might already have been retrieved from the Content-Location URI.
Content-Location値は、リクエスト時のこの特定のエンティティに対応するリソースの場所のステートメントです。このヘッダーフィールドは、最適化のみを目的として提供されています。このヘッダーフィールドの受信者は、送信されるエンティティが、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 this case, it might optimize by using the previously compiled grammar object.
たとえば、クライアントが文法マークアップをインラインで提供し、以前に特定のURIから取得した場合、そのURIは、Content-Locationヘッダーフィールドを使用してエンティティの一部として提供できます。これにより、認識エンジンなどのリソースがキャッシュを調べて、この文法が以前に取得、コンパイル、およびキャッシュされているかどうかを確認できます。この場合、以前にコンパイルされた文法オブジェクトを使用して最適化する場合があります。
If the Content-Location is a relative URI, the relative URI is interpreted relative to the Content-Base URI. This header field MAY occur on all messages.
Content-Locationが相対URIの場合、相対URIはContent-Base URIに関連して解釈されます。このヘッダーフィールドは、すべてのメッセージで発生する場合があります。
This header field contains the length of the content of the message body (i.e., after the double CRLF following the last header field). Unlike in HTTP, it MUST be included in all messages that carry content beyond the header section. If it is missing, a default value of zero is assumed. Otherwise, it is interpreted according to [H14.13]. When a message having no use for a message body contains one, i.e., the Content-Length is non-zero, the receiver MUST ignore the content of the message body. This header field MAY occur on all messages.
このヘッダーフィールドには、メッセージ本文のコンテンツの長さが含まれます（つまり、最後のヘッダーフィールドに続く二重CRLFの後）。 HTTPとは異なり、ヘッダーセクションを超えてコンテンツを運ぶすべてのメッセージに含める必要があります。それがない場合は、デフォルト値のゼロが想定されます。それ以外の場合は、[H14.13]に従って解釈されます。メッセージ本文を使用しないメッセージに含まれる場合、つまりContent-Lengthがゼロ以外の場合、受信者はメッセージ本文の内容を無視する必要があります。このヘッダーフィールドは、すべてのメッセージで発生する場合があります。
content-length = "Content-Length" ":" 1*19DIGIT CRLF
When the recognizer or synthesizer needs to fetch documents or other resources, this header field controls the corresponding URI access properties. This defines the timeout for content that the server may need to fetch over the network. The value is interpreted to be in milliseconds and ranges from 0 to an implementation-specific maximum value. It is RECOMMENDED that servers be cautious about accepting long timeout values. The default value for this header field is implementation specific. This header field MAY occur in DEFINE-GRAMMAR, RECOGNIZE, SPEAK, SET-PARAMS, or GET-PARAMS.
認識エンジンまたはシンセサイザがドキュメントまたはその他のリソースをフェッチする必要がある場合、このヘッダーフィールドは対応するURIアクセスプロパティを制御します。これは、サーバーがネットワーク経由でフェッチする必要があるコンテンツのタイムアウトを定義します。値はミリ秒単位であると解釈され、0から実装固有の最大値までの範囲です。サーバーが長いタイムアウト値を受け入れることに注意することをお勧めします。このヘッダーフィールドのデフォルト値は実装固有です。このヘッダーフィールドは、DEFINE-GRAMMAR、RECOGNIZE、SPEAK、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
fetch-timeout = "Fetch-Timeout" ":" 1*19DIGIT CRLF
If the server implements content caching, it MUST adhere to the cache correctness rules of HTTP 1.1 [RFC2616] when accessing and caching stored content. In particular, the "expires" and "cache-control" header fields of the cached URI or document MUST be honored and 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 server for the session or request. The scope of the directive is based on the method it is sent on. If the directive is sent on a SET-PARAMS method, it applies for all requests for external documents the server makes during that session, unless it is overridden by a Cache-Control header field on an individual request. If the directives are sent on any other requests, they apply only to external document requests the server makes for that request. An empty Cache-Control header field on the GET-PARAMS method is a request for the server to return the current Cache-Control directives setting on the server. This header field MAY occur only on requests.
サーバーがコンテンツキャッシングを実装する場合、保存されたコンテンツにアクセスしてキャッシングするときは、HTTP 1.1 [RFC2616]のキャッシュの正確さのルールに準拠する必要があります。特に、キャッシュされたURIまたはドキュメントの「expires」および「cache-control」ヘッダーフィールドは尊重され、このヘッダーフィールドで設定されたCache-Controlデフォルトよりも優先される必要があります。 Cache-Controlディレクティブは、セッションまたはリクエストのためのサーバー上のデフォルトのキャッシュアルゴリズムを定義するために使用されます。ディレクティブのスコープは、送信されるメソッドに基づいています。ディレクティブがSET-PARAMSメソッドで送信される場合、個々のリクエストのCache-Controlヘッダーフィールドでオーバーライドされない限り、サーバーがそのセッション中に行う外部ドキュメントに対するすべてのリクエストに適用されます。ディレクティブが他の要求で送信される場合、ディレクティブは、サーバーがその要求に対して行う外部ドキュメント要求にのみ適用されます。 GET-PARAMSメソッドの空のCache-Controlヘッダーフィールドは、サーバーの現在のCache-Controlディレクティブ設定を返すサーバーへの要求です。このヘッダーフィールドは、リクエストでのみ発生する場合があります。
cache-control = "Cache-Control" ":"
[*WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )]
CRLF
cache-directive = "max-age" "=" delta-seconds
/ "max-stale" [ "=" delta-seconds ]
/ "min-fresh" "=" delta-seconds
delta-seconds = 1*19DIGIT
Here, delta-seconds is a decimal time value specifying the number of seconds since the instant the message response or data was received by the server.
ここで、delta-secondsは、メッセージ応答またはデータがサーバーによって受信された瞬間からの秒数を指定する10進数の時間値です。
The different cache-directive options allow the client to ask the server to override the default cache expiration mechanisms: max-age Indicates that the client can tolerate the server using content 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 a response based on stale data.
さまざまなキャッシュディレクティブオプションを使用すると、クライアントはサーバーにデフォルトのキャッシュ有効期限メカニズムを上書きするように要求できます。max-ageクライアントが、指定された時間（秒単位）以下のコンテンツを使用してサーバーを許容できることを示します。 「max-stale」ディレクティブも含まれていない限り、クライアントは古いデータに基づく応答を受け入れる用意がありません。
min-fresh Indicates that the client is willing to accept a server response with cached data whose expiration is no less than its current age plus the specified time in seconds. If the server's cache time-to-live exceeds the client-supplied min-fresh value, the server MUST NOT utilize cached content.
min-freshクライアントが、有効期限が現在の経過時間と指定された時間（秒単位）を足したものであるキャッシュデータを含むサーバー応答を受け入れる用意があることを示します。サーバーのキャッシュ存続時間がクライアント提供のmin-fresh値を超える場合、サーバーはキャッシュされたコンテンツを利用してはなりません（MUST NOT）。
max-stale Indicates that the client is willing to allow a server to utilize cached data that has exceeded its expiration time. If "max-stale" is assigned a value, then the client is willing to allow the server to use cached data 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 allow the server to use stale data of any age.
max-staleクライアントが、サーバーが有効期限を超えたキャッシュデータを利用することを許可する意思があることを示します。 「max-stale」に値が割り当てられている場合、クライアントは、指定された秒数を超えて有効期限を超えたキャッシュデータをサーバーが使用することを許可します。 「max-stale」に値が割り当てられていない場合、クライアントはサーバーが任意の年齢の古いデータを使用することを許可します。
If the server cache is requested to use stale response/data without validation, it MAY do so 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 to the corresponding URI).
検証なしで古い応答/データを使用するようにサーバーキャッシュが要求された場合、キャッシュ検証に関する「MUST」レベルの要件（たとえば、「must-revalidate」のCache-Controlディレクティブが対応するURIに関連するHTTP 1.1仕様）。
If both the MRCPv2 Cache-Control directive and the cached entry on the 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.
MRCPv2 Cache-Controlディレクティブとサーバー上のキャッシュされたエントリの両方に「max-age」ディレクティブが含まれている場合、その要求のキャッシュされたエントリの鮮度を判断するために、2つの値の小さい方が使用されます。
This header field MAY be sent as part of a SET-PARAMS/GET-PARAMS method to set or retrieve the logging tag for logs generated by the server. Once set, the value persists until a new value is set or the session ends. The MRCPv2 server MAY provide a mechanism to create subsets of its output logs so that system administrators can examine or extract only the log file portion during which the logging tag was set to a certain value.
このヘッダーフィールドは、サーバーによって生成されたログのログタグを設定または取得するために、SET-PARAMS / GET-PARAMSメソッドの一部として送信される場合があります。値が設定されると、新しい値が設定されるか、セッションが終了するまで、値が保持されます。 MRCPv2サーバーは、システム管理者がログタグが特定の値に設定されているログファイル部分のみを調査または抽出できるように、その出力ログのサブセットを作成するメカニズムを提供する場合があります。
It is RECOMMENDED that clients include in the logging tag information to identify the MRCPv2 client User Agent, so that one can determine which MRCPv2 client request generated a given log message at the server. It is also RECOMMENDED that MRCPv2 clients not log personally identifiable information such as credit card numbers and national identification numbers.
クライアントがMRCPv2クライアントのユーザーエージェントを識別するためにログタグ情報に含めることをお勧めします。これにより、どのMRCPv2クライアント要求がサーバーで特定のログメッセージを生成したかを判別できます。また、MRCPv2クライアントは、クレジットカード番号や国民識別番号などの個人を特定できる情報をログに記録しないことをお勧めします。
logging-tag = "Logging-Tag" ":" 1*UTFCHAR CRLF
Since the associated HTTP client on an MRCPv2 server fetches documents for processing on behalf of the MRCPv2 client, the cookie store in the HTTP client of the MRCPv2 server is treated as an extension of the cookie store in the HTTP client of the MRCPv2 client. This requires that the MRCPv2 client and server be able to synchronize their common cookie store as needed. To enable the MRCPv2 client to push its stored cookies to the MRCPv2 server and get new cookies from the MRCPv2 server stored back to the MRCPv2 client, the Set-Cookie entity-header field MAY be included in MRCPv2 requests to update the cookie store on a server and be returned in final MRCPv2 responses or events to subsequently update the client's own cookie store. The stored cookies on the server persist for the duration of the MRCPv2 session and MUST be destroyed at the end of the session. To ensure support for cookies, MRCPv2 clients and servers MUST support the Set-Cookie entity-header field.
MRCPv2サーバー上の関連付けられたHTTPクライアントは、MRCPv2クライアントの代わりに処理するドキュメントをフェッチするため、MRCPv2サーバーのHTTPクライアントのCookieストアは、MRCPv2クライアントのHTTPクライアントのCookieストアの拡張として扱われます。これには、MRCPv2クライアントとサーバーが、必要に応じて共通のCookieストアを同期できる必要があります。 MRCPv2クライアントが保存されたCookieをMRCPv2サーバーにプッシュし、MRCPv2サーバーから新しいCookieを取得してMRCPv2クライアントに戻すには、Set-CookieエンティティヘッダーフィールドをMRCPv2リクエストに含めて、サーバーに送信し、最終的なMRCPv2応答またはイベントで返されて、その後クライアント自身のCookieストアを更新します。サーバーに保存されたCookieは、MRCPv2セッションの間存続し、セッションの最後に破棄する必要があります。 Cookieを確実にサポートするには、MRCPv2クライアントとサーバーはSet-Cookieエンティティヘッダーフィールドをサポートする必要があります。
Note that it is the MRCPv2 client that determines which, if any, cookies are sent to the server. There is no requirement that all cookies be shared. Rather, it is RECOMMENDED that MRCPv2 clients communicate only cookies needed by the MRCPv2 server to process its requests.
サーバーに送信されるCookieがある場合は、それを決定するのはMRCPv2クライアントです。すべてのCookieを共有する必要はありません。むしろ、MRCPv2クライアントは、MRCPv2サーバーが要求を処理するために必要なCookieのみを通信することをお勧めします。
set-cookie = "Set-Cookie:" cookies CRLF
cookies = cookie *("," *LWS cookie)
cookie = attribute "=" value *(";" cookie-av)
cookie-av = "Comment" "=" value
/ "Domain" "=" value
/ "Max-Age" "=" value
/ "Path" "=" value
/ "Secure"
/ "Version" "=" 1*19DIGIT
/ "Age" "=" delta-seconds
set-cookie = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av / age-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
non-zero-digit = %x31-39
domain-av = "Domain=" domain-value
domain-value = <subdomain>
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
age-av = "Age=" delta-seconds
The Set-Cookie header field is specified in RFC 6265 [RFC6265]. The "Age" attribute is introduced in this specification to indicate the age of the cookie and is OPTIONAL. An MRCPv2 client or server MUST calculate the age of the cookie according to the age calculation rules in the HTTP/1.1 specification [RFC2616] and append the "Age" attribute accordingly. This attribute is provided because time may have passed since the client received the cookie from an HTTP server. Rather than having the client reduce Max-Age by the actual age, it passes Max-Age verbatim and appends the "Age" attribute, thus maintaining the cookie as received while still accounting for the fact that time has passed.
Set-CookieヘッダーフィールドはRFC 6265 [RFC6265]で指定されています。 「年齢」属性は、Cookieの年齢を示すためにこの仕様で導入され、オプションです。 MRCPv2クライアントまたはサーバーは、HTTP / 1.1仕様[RFC2616]の経過時間計算ルールに従ってCookieの経過時間を計算し、それに応じて「経過時間」属性を追加する必要があります。この属性が提供されるのは、クライアントがHTTPサーバーからCookieを受信してから時間が経過している可能性があるためです。クライアントにMax-Ageを実際の年齢で削減させるのではなく、Max-Ageを逐語的に渡し、「Age」属性を追加します。これにより、時間が経過したという事実を考慮しながら、受信したCookieを維持します。
The MRCPv2 client or server MUST supply defaults for the "Domain" and "Path" attributes, as specified in RFC 6265, if they are omitted by the HTTP origin server. Note that there is no leading dot present in the "Domain" attribute value in this case. Although an explicitly specified "Domain" value received via the HTTP protocol may be modified to include a leading dot, an MRCPv2 client or server MUST NOT modify the "Domain" value when received via the MRCPv2 protocol.
MRCPv2クライアントまたはサーバーは、HTTPオリジンサーバーによって省略されている場合、RFC 6265で指定されている「ドメイン」および「パス」属性のデフォルトを提供する必要があります。この場合、「ドメイン」属性値には先行ドットがないことに注意してください。 HTTPプロトコルを介して受信した明示的に指定された「ドメイン」値は、先頭のドットを含むように変更できますが、MRCPv2プロトコルを介して受信した場合、MRCPv2クライアントまたはサーバーは「ドメイン」値を変更してはなりません。
An MRCPv2 client or server MAY combine multiple cookie header fields of the same type into a single "field-name:field-value" pair as described in Section 6.2.
セクション6.2で説明されているように、MRCPv2クライアントまたはサーバーは、同じタイプの複数のCookieヘッダーフィールドを1つの「フィールド名：フィールド値」のペアに結合してもよい（MAY）。
The Set-Cookie header field MAY be specified in any request that subsequently results in the server performing an HTTP access. When a server receives new cookie information from an HTTP origin server, and assuming the cookie store is modified according to RFC 6265, the server MUST return the new cookie information in the MRCPv2 COMPLETE response or event, as appropriate, to allow the client to update its own cookie store.
Set-Cookieヘッダーフィールドは、その後サーバーがHTTPアクセスを実行する結果となる要求で指定される場合があります。サーバーがHTTP起点サーバーから新しいCookie情報を受信し、CookieストアがRFC 6265に従って変更されていると想定した場合、サーバーは、クライアントが更新できるように、MRCPv2 COMPLETE応答またはイベントで新しいCookie情報を返す必要があります。独自のCookieストア。
The SET-PARAMS request MAY specify the Set-Cookie header field to update the cookie store on a server. The GET-PARAMS request MAY be used to return the entire cookie store of "Set-Cookie" type cookies to the client.
SET-PARAMSリクエストは、サーバーのCookieストアを更新するためにSet-Cookieヘッダーフィールドを指定する場合があります。 GET-PARAMSリクエストを使用して、「Set-Cookie」タイプのCookieのCookieストア全体をクライアントに返すことができます。
This set of header fields allows for the client to set or retrieve vendor-specific parameters.
このヘッダーフィールドのセットにより、クライアントはベンダー固有のパラメーターを設定または取得できます。
vendor-specific = "Vendor-Specific-Parameters" ":" [vendor-specific-av-pair *(";" vendor-specific-av-pair)] CRLF
vendor-specific = "Vendor-Specific-Parameters" "：" [vendor-specific-av-pair *（ ";" vendor-specific-av-pair）] CRLF
vendor-specific-av-pair = vendor-av-pair-name "=" value
vendor-specific-av-pair = vendor-av-pair-name "="値
vendor-av-pair-name = 1*UTFCHAR
Header fields of this form MAY be sent in any method (request) and are used to manage implementation-specific parameters on the server side. The vendor-av-pair-name follows the reverse Internet Domain Name convention (see Section 13.1.6 for syntax and registration information). The value of the vendor attribute is specified after the "=" symbol and MAY be quoted. For example:
このフォームのヘッダーフィールドは、任意のメソッド（リクエスト）で送信でき、サーバー側の実装固有のパラメーターを管理するために使用されます。 vendor-av-pair-nameは、インターネットドメイン名の逆の規則に従います（構文と登録情報については、セクション13.1.6を参照してください）。ベンダー属性の値は、「=」記号の後に指定され、引用符で囲まれる場合があります。例えば：
com.example.companyA.paramxyz=256 com.example.companyA.paramabc=High com.example.companyB.paramxyz=Low
com.example.companyA.paramxyz = 256 com.example.companyA.paramabc =高com.example.companyB.paramxyz =低
When used in GET-PARAMS to get the current value of these parameters from the server, this header field value MAY contain a semicolon-separated list of implementation-specific attribute names.
サーバーからこれらのパラメーターの現在の値を取得するためにGET-PARAMSで使用される場合、このヘッダーフィールド値には、実装固有の属性名のセミコロン区切りのリストが含まれる場合があります。
Result data from the server for the Recognizer and Verifier resources is carried as a typed media entity in the MRCPv2 message body of various events. The Natural Language Semantics Markup Language (NLSML), an XML markup based on an early draft from the W3C, is the default standard for returning results back to the client. Hence, all servers implementing these resource types MUST support the media type 'application/nlsml+xml'. The Extensible MultiModal Annotation (EMMA) [W3C.REC-emma-20090210] format can be used to return results as well. This can be done by negotiating the format at session establishment time with SDP (a=resultformat:application/emma+xml) or with SIP (Allow/Accept). With SIP, for example, if a client wants results in EMMA, an MRCPv2 server can route the request to another server that supports EMMA by inspecting the SIP header fields, rather than having to inspect the SDP.
サーバーからのRecognizerリソースとVerifierリソースの結果データは、さまざまなイベントのMRCPv2メッセージ本文で型付きメディアエンティティとして伝送されます。自然言語セマンティクスマークアップ言語（NLSML）は、W3Cの初期ドラフトに基づくXMLマークアップであり、結果をクライアントに返すためのデフォルトの標準です。したがって、これらのリソースタイプを実装するすべてのサーバーは、メディアタイプ「application / nlsml + xml」をサポートする必要があります。 Extensible MultiModal Annotation（EMMA）[W3C.REC-emma-20090210]形式を使用して、結果を返すこともできます。これは、SDP（a = resultformat：application / emma + xml）またはSIP（Allow / Accept）を使用して、セッション確立時にフォーマットをネゴシエートすることで実行できます。たとえば、SIPを使用すると、クライアントがEMMAの結果を必要とする場合、MRCPv2サーバーは、SDPを検査する代わりに、SIPヘッダーフィールドを検査することにより、EMMAをサポートする別のサーバーに要求をルーティングできます。
MRCPv2 uses this representation to convey content among the clients and servers that generate and make use of the markup. MRCPv2 uses NSLML specifically to convey recognition, enrollment, and verification results between the corresponding resource on the MRCPv2 server and the MRCPv2 client. Details of this result format are fully described in Section 6.3.1.
MRCPv2はこの表現を使用して、マークアップを生成および利用するクライアントとサーバー間でコンテンツを伝達します。 MRCPv2はNSLMLを特に使用して、MRCPv2サーバー上の対応するリソースとMRCPv2クライアントの間で認識、登録、および検証の結果を伝達します。この結果形式の詳細については、セクション6.3.1で詳しく説明しています。
Content-Type:application/nlsml+xml Content-Length:...
Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="http://theYesNoGrammar">
<interpretation>
<instance>
<ex:response>yes</ex:response>
</instance>
<input>OK</input>
</interpretation>
</result>
Result Example
結果の例
The Natural Language Semantics Markup Language (NLSML) is an XML data structure with elements and attributes designed to carry result information from recognizer (including enrollment) and verifier resources. The normative definition of NLSML is the RelaxNG schema in Section 16.1. Note that the elements and attributes of this format are defined in the MRCPv2 namespace. In the result structure, they must either be prefixed by a namespace prefix declared within the result or must be children of an element identified as belonging to the respective namespace. For details on how to use XML Namespaces, see [W3C.REC-xml-names11-20040204]. Section 2 of [W3C.REC-xml-names11-20040204] provides details on how to declare namespaces and namespace prefixes.
自然言語セマンティクスマークアップ言語（NLSML）は、認識機能（登録を含む）および検証リソースからの結果情報を運ぶように設計された要素と属性を持つXMLデータ構造です。 NLSMLの規範的な定義は、セクション16.1のRelaxNGスキーマです。この形式の要素と属性はMRCPv2名前空間で定義されていることに注意してください。結果構造では、結果内で宣言された名前空間接頭辞が前に付けられるか、それぞれの名前空間に属していると識別された要素の子である必要があります。 XML名前空間の使用方法の詳細については、[W3C.REC-xml-names11-20040204]を参照してください。 [W3C.REC-xml-names11-20040204]のセクション2では、名前空間と名前空間プレフィックスを宣言する方法の詳細を説明しています。
The root element of NLSML is <result>. Optional child elements are <interpretation>, <enrollment-result>, and <verification-result>, at least one of which must be present. A single <result> MAY contain any or all of the optional child elements. Details of the <result> and <interpretation> elements and their subelements and attributes can be found in Section 9.6. Details of the <enrollment-result> element and its subelements can be found in Section 9.7. Details of the <verification-result> element and its subelements can be found in Section 11.5.2.
NLSMLのルート要素は<result>です。オプションの子要素は、<interpretation>、<enrollment-result>、および<verification-result>で、少なくとも1つは存在している必要があります。単一の<result>には、オプションの子要素の一部またはすべてが含まれる場合があります。 <result>要素と<interpretation>要素、およびそれらのサブ要素と属性の詳細は、セクション9.6を参照してください。 <enrollment-result>要素とそのサブ要素の詳細については、セクション9.7を参照してください。 <verification-result>要素とそのサブ要素の詳細は、セクション11.5.2を参照してください。
Server resources may be discovered and their capabilities learned by clients through standard SIP machinery. The client MAY issue a SIP OPTIONS transaction to a server, which has the effect of requesting the capabilities of the server. The server MUST respond to such a request with an SDP-encoded description of its capabilities according to RFC 3264 [RFC3264]. The MRCPv2 capabilities are described by a single "m=" line containing the media type "application" and transport type "TCP/TLS/MRCPv2" or "TCP/MRCPv2". There MUST be one "resource" attribute for each media resource that the server supports, and it has the resource type identifier as its value.
サーバーリソースが検出され、その機能が標準のSIP機構を介してクライアントによって学習されます。クライアントはサーバーにSIP OPTIONSトランザクションを発行することができます（MAY）。これはサーバーの機能を要求する効果があります。サーバーは、RFC 3264 [RFC3264]に従って、その機能のSDPエンコードされた説明でそのような要求に応答する必要があります。 MRCPv2機能は、メディアタイプ「アプリケーション」とトランスポートタイプ「TCP / TLS / MRCPv2」または「TCP / MRCPv2」を含む単一の「m =」行で記述されます。サーバーがサポートするメディアリソースごとに1つの「リソース」属性が存在する必要があり、その値としてリソースタイプ識別子を持っています。
The SDP description MUST also contain "m=" lines describing the audio capabilities and the coders the server supports.
SDPの説明には、オーディオ機能とサーバーがサポートするコーダーを説明する「m =」行も含める必要があります。
In this example, the client uses the SIP OPTIONS method to query the capabilities of the MRCPv2 server.
この例では、クライアントはSIP OPTIONSメソッドを使用してMRCPv2サーバーの機能を照会します。
C->S:
OPTIONS sip:mrcp@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bf7
Max-Forwards:6
To:<sip:mrcp@example.com>
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:63104 OPTIONS
Contact:<sip:sarvi@client.example.com>
Accept:application/sdp
Content-Length:0
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bf7;received=192.0.32.10 To:<sip:mrcp@example.com>;tag=62784 From:Sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:63104 OPTIONS Contact:<sip:mrcp@server.example.com> Allow:INVITE, ACK, CANCEL, OPTIONS, BYE Accept:application/sdp Accept-Encoding:gzip Accept-Language:en Supported:foo Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bf7; received = 192.0.32.10 To：<sip：mrcp@example.com>; tag = 62784 From：Sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：63104オプションの連絡先：<sip：mrcp@server.example.com>許可：INVITE、ACK、CANCEL、OPTIONS、BYE Accept：application / sdp Accept-Encoding：gzip Accept-Language：enサポート：foo Content-Type：application / sdp Content-長さ：...
v=0
o=sarvi 2890844536 2890842811 IN IP4 192.0.2.12
s=-
i=MRCPv2 server capabilities
c=IN IP4 192.0.2.12/127
t=0 0
m=application 0 TCP/TLS/MRCPv2 1
a=resource:speechsynth
a=resource:speechrecog
a=resource:speakverify
m=audio 0 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Using SIP OPTIONS for MRCPv2 Server Capability Discovery
MRCPv2サーバー機能ディスカバリーのためのSIPオプションの使用
This resource processes text markup provided by the client and generates a stream of synthesized speech in real time. Depending upon the server implementation and capability of this resource, the client can also dictate parameters of the synthesized speech such as voice characteristics, speaker speed, etc.
このリソースは、クライアントによって提供されたテキストマークアップを処理し、リアルタイムで合成音声のストリームを生成します。サーバーの実装とこのリソースの機能に応じて、クライアントは、音声特性、話者の速度など、合成音声のパラメーターを指示することもできます。
The synthesizer resource is controlled by MRCPv2 requests from the client. Similarly, the resource can respond to these requests or generate asynchronous events to the client to indicate conditions of interest to the client during the generation of the synthesized speech stream.
シンセサイザリソースは、クライアントからのMRCPv2要求によって制御されます。同様に、リソースはこれらの要求に応答するか、クライアントに非同期イベントを生成して、合成音声ストリームの生成中にクライアントが関心のある状態を示すことができます。
This section applies for the following resource types:
このセクションは、次のリソースタイプに適用されます。
o speechsynth
o スピーチシンセ
o basicsynth
o ベーシックシンセ
The capabilities of these resources are defined in Section 3.1.
これらのリソースの機能は、セクション3.1で定義されています。
The synthesizer maintains a state machine to process MRCPv2 requests from the client. The state transitions shown below describe the states of the synthesizer and reflect the state of the request at the head of the synthesizer resource queue. A SPEAK request in the PENDING state can be deleted or stopped by a STOP request without affecting the state of the resource.
シンセサイザは、クライアントからのMRCPv2要求を処理するステートマシンを維持します。以下に示す状態遷移は、シンセサイザの状態を表し、シンセサイザリソースキューの先頭にあるリクエストの状態を反映しています。 PENDING状態のSPEAK要求は、リソースの状態に影響を与えることなく、STOP要求によって削除または停止できます。
Idle Speaking Paused
State State State
| | |
|----------SPEAK-------->| |--------|
|<------STOP-------------| CONTROL |
|<----SPEAK-COMPLETE-----| |------->|
|<----BARGE-IN-OCCURRED--| |
| |---------| |
| CONTROL |-----------PAUSE--------->|
| |-------->|<----------RESUME---------|
| | |----------|
|----------| | PAUSE |
| BARGE-IN-OCCURRED | |--------->|
|<---------| |----------| |
| | SPEECH-MARKER |
| |<---------| |
|----------| |----------| |
| STOP | RESUME |
| | |<---------| |
|<---------| | |
|<---------------------STOP-------------------------|
|----------| | |
| DEFINE-LEXICON | |
| | | |
|<---------| | |
|<---------------BARGE-IN-OCCURRED------------------|
Synthesizer State Machine
シンセサイザーステートマシン
The synthesizer supports the following methods.
シンセサイザは、次のメソッドをサポートしています。
synthesizer-method = "SPEAK"
/ "STOP"
/ "PAUSE"
/ "RESUME"
/ "BARGE-IN-OCCURRED"
/ "CONTROL"
/ "DEFINE-LEXICON"
The synthesizer can generate the following events.
シンセサイザは、次のイベントを生成できます。
synthesizer-event = "SPEECH-MARKER" / "SPEAK-COMPLETE"
シンセサイザイベント= "SPEECH-MARKER" / "SPEAK-COMPLETE"
A synthesizer method can contain header fields containing request options and information to augment the Request, Response, or Event it is associated with.
シンセサイザメソッドには、リクエストオプションと、関連付けられているリクエスト、レスポンス、またはイベントを拡張するための情報を含むヘッダーフィールドを含めることができます。
synthesizer-header = jump-size
/ kill-on-barge-in
/ speaker-profile
/ completion-cause
/ completion-reason
/ voice-parameter
/ prosody-parameter
/ speech-marker
/ speech-language
/ fetch-hint
/ audio-fetch-hint
/ failed-uri
/ failed-uri-cause
/ speak-restart
/ speak-length
/ load-lexicon
/ lexicon-search-order
This header field MAY be specified in a CONTROL method and controls the amount to jump forward or backward in an active SPEAK request. A '+' or '-' indicates a relative value to what is being currently played. This header field MAY also be specified in a SPEAK request as a desired offset into the synthesized speech. In this case, the synthesizer MUST begin speaking from this amount of time into the speech markup. Note that an offset that extends beyond the end of the produced speech will result in audio of length zero. The different speech length units supported are dependent on the synthesizer implementation. If the synthesizer resource does not support a unit for the operation, the resource MUST respond with a status-code of 409 "Unsupported Header Field Value".
このヘッダーフィールドはCONTROLメソッドで指定される場合があり、アクティブなSPEAK要求で前後にジャンプする量を制御します。 「+」または「-」は、現在再生されているものに対する相対値を示します。このヘッダーフィールドは、SPEAK要求で、合成音声への必要なオフセットとして指定することもできます。この場合、シンセサイザはこの時間からスピーチマークアップに向かって話し始める必要があります。生成されたスピーチの終わりを超えるオフセットは、長さがゼロのオーディオになることに注意してください。サポートされるさまざまな音声長単位は、シンセサイザの実装によって異なります。シンセサイザリソースが操作のユニットをサポートしない場合、リソースは409 "Unsupported Header Field Value"のステータスコードで応答する必要があります。
jump-size = "Jump-Size" ":" speech-length-value CRLF
jump-size = "Jump-Size" "：" speech-length-value CRLF
speech-length-value = numeric-speech-length / text-speech-length
スピーチ長さ値=数値スピーチ長/テキストスピーチ長さ
text-speech-length = 1*UTFCHAR SP "Tag"
numeric-speech-length = ("+" / "-") positive-speech-length
positive-speech-length = 1*19DIGIT SP numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
This header field 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.
このヘッダーフィールドは、 "kill-on-barge-in"サポートを有効にするためにSPEAKメソッドの一部として送信される場合があります。有効にした場合、SPEAKメソッドは、信号検出リソースによって検出されたDTMF入力によって、または音声認識リソースによって検出または認識された音声の開始によって中断されます。
kill-on-barge-in = "Kill-On-Barge-In" ":" BOOLEAN CRLF
kill-on-barge-in = "Kill-On-Barge-In" "：" BOOLEAN CRLF
The client MUST send a BARGE-IN-OCCURRED method to the synthesizer resource when it receives a barge-in-able event from any source. This source could be a synthesizer resource or signal detector resource and MAY be either local or distributed. If this header field is not specified in a SPEAK request or explicitly set by a SET-PARAMS, the default value for this header field is "true".
クライアントは、任意のソースから割り込み可能なイベントを受信したときに、シンセサイザーリソースにBARGE-IN-OCCURREDメソッドを送信する必要があります。このソースは、シンセサイザリソースまたは信号検出器リソースであり、ローカルまたは分散のいずれかである場合があります。このヘッダーフィールドがSPEAK要求で指定されていないか、SET-PARAMSによって明示的に設定されていない場合、このヘッダーフィールドのデフォルト値は「true」です。
If the recognizer or signal detector resource is on the same server as the synthesizer and both are part of the same session, the server MAY work with both to provide internal notification to the synthesizer so that audio may be stopped without having to wait for the client's BARGE-IN-OCCURRED event.
認識機能または信号検出リソースがシンセサイザと同じサーバー上にあり、両方が同じセッションの一部である場合、サーバーは両方と連携してシンセサイザに内部通知を提供し、クライアントの待機をせずにオーディオを停止できるようにする場合があります。 BARGE-IN-OCCURREDイベント。
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).
Kill-On-Barge-Inを使用してユーザーにプロンプトを再生し、入力を要求する場合、クライアントが最適なパフォーマンスとユーザーエクスペリエンスのためにSPEAKリクエストより先にRECOGNIZEリクエストを発行することをお勧めします。このようにして、プロンプトの再生が始まる前に認識エンジンがオンラインであることが保証され、ユーザーの音声が最初から切り捨てられません（特にパワーユーザーの場合）。
This header field MAY be part of the SET-PARAMS/GET-PARAMS or SPEAK request from the client to the server and specifies a URI that references the profile of the speaker. Speaker profiles are collections of voice parameters like gender, accent, etc.
このヘッダーフィールドは、クライアントからサーバーへのSET-PARAMS / GET-PARAMSまたはSPEAKリクエストの一部である場合があり、スピーカーのプロファイルを参照するURIを指定します。スピーカープロファイルは、性別、アクセントなどの音声パラメータのコレクションです。
speaker-profile = "Speaker-Profile" ":" uri CRLF
Speaker-profile = "Speaker-Profile" "：" uri CRLF
This header field MUST be specified in a SPEAK-COMPLETE event coming from the synthesizer resource to the client. This indicates the reason the SPEAK request completed.
このヘッダーフィールドは、シンセサイザリソースからクライアントに送信されるSPEAK-COMPLETEイベントで指定する必要があります。これは、SPEAK要求が完了した理由を示します。
completion-cause = "Completion-Cause" ":" 3DIGIT SP 1*VCHAR CRLF
completion-cause = "Completion-Cause" "：" 3DIGIT SP 1 * VCHAR 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. |
| 006 | lexicon-load-failure | Lexicon loading failed. |
| 007 | cancelled | A prior SPEAK request failed |
| | | while this one was still in |
| | | the queue. |
+------------+-----------------------+------------------------------+
Synthesizer Resource Completion Cause Codes
シンセサイザーリソース完了原因コード
This header field MAY be specified in a SPEAK-COMPLETE event coming from the synthesizer resource to the client. This contains the reason text behind the SPEAK request completion. This header field communicates text describing the reason for the failure, such as an error in parsing the speech markup text.
このヘッダーフィールドは、シンセサイザリソースからクライアントに送信されるSPEAK-COMPLETEイベントで指定される場合があります。これには、SPEAK要求完了の背後にある理由テキストが含まれます。このヘッダーフィールドは、スピーチマークアップテキストの解析エラーなど、失敗の理由を説明するテキストを伝えます。
completion-reason = "Completion-Reason" ":" quoted-string CRLF
completion-reason = "Completion-Reason" "："引用文字列CRLF
The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients MUST NOT interpret the completion reason text.
完了理由のテキストは、クライアントがログで使用するため、およびデバッグと計測の目的で提供されます。クライアントは完了理由テキストを解釈してはなりません。
This set of header fields defines the voice of the speaker.
このヘッダーフィールドのセットは、話者の声を定義します。
voice-parameter = voice-gender
/ voice-age
/ voice-variant
/ voice-name
voice-gender = "Voice-Gender:" voice-gender-value CRLF
voice-gender-value = "male"
/ "female"
/ "neutral"
voice-age = "Voice-Age:" 1*3DIGIT CRLF
voice-variant = "Voice-Variant:" 1*19DIGIT CRLF
voice-name = "Voice-Name:"
1*UTFCHAR *(1*WSP 1*UTFCHAR) CRLF
The "Voice-" parameters are derived from the similarly named attributes of the voice element specified in W3C's Speech Synthesis Markup Language Specification (SSML) [W3C.REC-speech-synthesis-20040907]. Legal values for these parameters are as defined in that specification.
「Voice-」パラメータは、W3Cの音声合成マークアップ言語仕様（SSML）[W3C.REC-speech-synthesis-20040907]で指定されている音声要素の同様の名前の属性から派生します。これらのパラメータの有効な値は、その仕様で定義されているとおりです。
These header fields MAY be sent in SET-PARAMS or GET-PARAMS requests to define or get default values for the entire session or MAY be sent in the SPEAK request to define default values for that SPEAK request. Note that SSML content can itself set these values internal to the SSML document, of course.
これらのヘッダーフィールドは、セッション全体のデフォルト値を定義または取得するためにSET-PARAMSまたはGET-PARAMSリクエストで送信される場合と、そのSPEAKリクエストのデフォルト値を定義するためにSPEAKリクエストで送信される場合があります。もちろん、SSMLコンテンツ自体がSSMLドキュメントの内部でこれらの値を設定できることに注意してください。
Voice parameter header fields MAY 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 MUST reject the request with a status-code of 403 "Unsupported Header Field".
音声パラメーターヘッダーフィールドもCONTROLメソッドで送信して、進行中のSPEAKリクエストに影響を与え、その動作をその場で変更できます。シンセサイザリソースがこの操作をサポートしない場合、ステータスコード403 "Unsupported Header Field"でリクエストを拒否する必要があります。
This set of header fields defines the prosody of the speech.
このヘッダーフィールドのセットは、スピーチの韻律を定義します。
prosody-parameter = "Prosody-" prosody-param-name ":" prosody-param-value CRLF
prosody-parameter = "Prosody-" prosody-param-name "：" prosody-param-value CRLF
prosody-param-name = 1*VCHAR
prosody-param-value = 1*VCHAR
prosody-param-name is any one of the attribute names under the prosody element specified in W3C's Speech Synthesis Markup Language Specification [W3C.REC-speech-synthesis-20040907]. The prosody-param-value is any one of the value choices of the corresponding prosody element attribute from that specification.
prosody-param-nameは、W3Cの音声合成マークアップ言語仕様[W3C.REC-speech-synthesis-20040907]で指定されているprosody要素の下の属性名のいずれかです。 prosody-param-valueは、その仕様からの対応するprosody要素属性の値の選択肢の1つです。
These header fields MAY be sent in SET-PARAMS or GET-PARAMS requests to define or get default values for the entire session or MAY be sent in the SPEAK request to define default values for that SPEAK request. Furthermore, these attributes can be part of the speech text marked up in SSML.
これらのヘッダーフィールドは、セッション全体のデフォルト値を定義または取得するためにSET-PARAMSまたはGET-PARAMSリクエストで送信される場合と、そのSPEAKリクエストのデフォルト値を定義するためにSPEAKリクエストで送信される場合があります。さらに、これらの属性は、SSMLでマークアップされた音声テキストの一部にすることができます。
The prosody parameter header fields in the SET-PARAMS or SPEAK request only apply if the speech data is of type 'text/plain' and does not use a speech markup format.
SET-PARAMSまたはSPEAKリクエストの韻律パラメータヘッダーフィールドは、音声データのタイプが「text / plain」で、音声マークアップ形式を使用しない場合にのみ適用されます。
These prosody parameter header fields MAY 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 MUST respond back to the client with a status-code of 403 "Unsupported Header Field".
これらの韻律パラメータヘッダーフィールドは、進行中のSPEAKリクエストに影響を与え、その動作をその場で変更するために、CONTROLメソッドでも送信される場合があります。シンセサイザリソースがこの操作をサポートしていない場合、403 "Unsupported Header Field"のステータスコードでクライアントに応答する必要があります。
This header field contains timestamp information in a "timestamp" field. This is a Network Time Protocol (NTP) [RFC5905] timestamp, a 64-bit number in decimal form. It MUST be synced with the Real-Time Protocol (RTP) [RFC3550] timestamp of the media stream through the Real-Time Control Protocol (RTCP) [RFC3550].
このヘッダーフィールドには、「タイムスタンプ」フィールドにタイムスタンプ情報が含まれています。これは、Network Time Protocol（NTP）[RFC5905]タイムスタンプで、10進形式の64ビットの数値です。リアルタイム制御プロトコル（RTCP）[RFC3550]を介して、メディアストリームのリアルタイムプロトコル（RTP）[RFC3550]タイムスタンプと同期する必要があります。
Markers are bookmarks that are defined within the markup. Most speech markup formats provide mechanisms to embed marker fields within speech texts. The synthesizer generates SPEECH-MARKER events when it reaches these marker fields. This header field MUST be part of the SPEECH-MARKER event and contain the marker tag value after the timestamp, separated by a semicolon. In these events, the timestamp marks the time the text corresponding to the marker was emitted as speech by the synthesizer.
マーカーは、マークアップ内で定義されるブックマークです。ほとんどの音声マークアップ形式は、マーカーテキストを音声テキスト内に埋め込むメカニズムを提供します。シンセサイザは、これらのマーカーフィールドに到達すると、SPEECH-MARKERイベントを生成します。このヘッダーフィールドは、SPEECH-MARKERイベントの一部である必要があり、セミコロンで区切られたタイムスタンプの後にマーカータグ値を含める必要があります。これらのイベントでは、タイムスタンプは、マーカーに対応するテキストがシンセサイザによってスピーチとして放出された時間を示します。
This header field MUST also be returned in responses to STOP, CONTROL, and BARGE-IN-OCCURRED methods, in the SPEAK-COMPLETE event, and in an IN-PROGRESS SPEAK response. In these messages, if any markers have been encountered for the current SPEAK, the marker tag value MUST be the last embedded marker encountered. If no markers have yet been encountered for the current SPEAK, only the timestamp is REQUIRED. Note that in these events, the purpose of this header field is to provide timestamp information associated with important events within the lifecycle of a request (start of SPEAK processing, end of SPEAK processing, receipt of CONTROL/STOP/BARGE-IN-OCCURRED).
このヘッダーフィールドは、STOP、CONTROL、およびBARGE-IN-OCCURREDメソッドへの応答、SPEAK-COMPLETEイベント、およびIN-PROGRESS SPEAK応答でも返される必要があります。これらのメッセージでは、現在のSPEAKでマーカーが検出された場合、マーカータグの値は最後に検出された埋め込みマーカーである必要があります。現在のSPEAKでマーカーがまだ検出されていない場合は、タイムスタンプのみが必要です。これらのイベントでは、このヘッダーフィールドの目的は、リクエストのライフサイクル（SPEAK処理の開始、SPEAK処理の終了、CONTROL / STOP / BARGE-IN-OCCURREDの受信）内の重要なイベントに関連付けられたタイムスタンプ情報を提供することです。 。
timestamp = "timestamp" "=" time-stamp-value
timestamp = "timestamp" "=" time-stamp-value
time-stamp-value = 1*20DIGIT
speech-marker = "Speech-Marker" ":"
timestamp
[";" 1*(UTFCHAR / %x20)] CRLF
This header field specifies the default language of the speech data if the language is not specified in the markup. The value of this header field MUST follow RFC 5646 [RFC5646] for its values. The header field MAY occur in SPEAK, SET-PARAMS, or GET-PARAMS requests.
言語がマークアップで指定されていない場合、このヘッダーフィールドは音声データのデフォルト言語を指定します。このヘッダーフィールドの値は、その値についてRFC 5646 [RFC5646]に従う必要があります。ヘッダーフィールドは、SPEAK、SET-PARAMS、またはGET-PARAMSリクエストで発生する場合があります。
speech-language = "Speech-Language" ":" 1*VCHAR CRLF
When the synthesizer needs to fetch documents or other resources like speech markup or audio files, this header field controls the corresponding URI access properties. This provides client policy on when the synthesizer should retrieve content from the server. A value of "prefetch" indicates the content MAY be downloaded when the request is received, whereas "safe" indicates that content MUST NOT be downloaded until actually referenced. 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" ":" ("prefetch" / "safe") CRLF
When the synthesizer needs to fetch documents or other resources like speech audio files, this header field controls the corresponding URI access properties. This provides client policy whether or not the synthesizer is permitted to attempt to optimize speech by pre-fetching audio. The value is either "safe" to say that audio is only fetched when it is referenced, never before; "prefetch" to permit, but not require the implementation 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" ":"
("prefetch" / "safe" / "stream") CRLF
When a synthesizer method needs a synthesizer to fetch or access a URI and the access fails, the server SHOULD provide the failed URI in this header field in the method response, unless there are multiple URI failures, in which case the server MUST provide one of the failed URIs in this header field in the method response.
シンセサイザメソッドがURIをフェッチまたはアクセスするためにシンセサイザを必要とし、アクセスが失敗した場合、サーバーは、メソッド応答のこのヘッダーフィールドに失敗したURIを提供する必要があります。メソッド応答のこのヘッダーフィールドの失敗したURI。
failed-uri = "Failed-URI" ":" absoluteURI CRLF
failed-uri = "Failed-URI" "：" absoluteURI CRLF
When a synthesizer method needs a synthesizer to fetch or access a URI and the access fails, the server MUST provide the URI-specific or protocol-specific response code for the URI in the Failed-URI header field in the method response through this header field. The value encoding is UTF-8 (RFC 3629 [RFC3629]) to accommodate any access protocol -- some access protocols might have a response string instead of a numeric response code.
シンセサイザメソッドがURIをフェッチまたはアクセスするためにシンセサイザを必要とし、アクセスが失敗した場合、サーバーは、このヘッダーフィールドを通じて、メソッド応答のFailed-URIヘッダーフィールドにURIのURI固有またはプロトコル固有の応答コードを提供する必要があります。 。値のエンコードはUTF-8（RFC 3629 [RFC3629]）であり、あらゆるアクセスプロトコルに対応します。一部のアクセスプロトコルには、数値応答コードの代わりに応答文字列が含まれる場合があります。
failed-uri-cause = "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
When a client issues a CONTROL request to a currently speaking synthesizer resource to jump backward, and the target jump point is before the start of the current SPEAK request, the current SPEAK request MUST restart from the beginning of its speech data and the server's response to the CONTROL request MUST contain this header field with a value of "true" indicating a restart.
クライアントが現在話しているシンセサイザーリソースにCONTROLリクエストを発行して後方にジャンプし、ターゲットジャンプポイントが現在のSPEAKリクエストの開始前である場合、現在のSPEAKリクエストは、音声データの最初とサーバーの応答から再開する必要があります。 CONTROLリクエストには、再起動を示す「true」の値を持つこのヘッダーフィールドを含める必要があります。
speak-restart = "Speak-Restart" ":" BOOLEAN CRLF
speak-restart = "Speak-Restart" "：" BOOLEAN CRLF
This header field MAY be specified in a CONTROL method to control the maximum length of speech to speak, relative to the current speaking point in the currently active SPEAK request. If numeric, the value MUST be a positive integer. If a header field with a Tag unit is specified, then the speech output continues until the tag is reached or the SPEAK request is completed, whichever comes first. This header field MAY be specified in a SPEAK request to indicate the length to speak from the speech data and is relative to the point in speech that the SPEAK request starts. The different speech length units supported are synthesizer implementation dependent. If a server does not support the specified unit, the server MUST respond with a status-code of 409 "Unsupported Header Field Value".
このヘッダーフィールドは、現在アクティブなSPEAK要求の現在の発話ポイントを基準にして、発話する音声の最大長を制御するためにCONTROLメソッドで指定される場合があります。数値の場合、値は正の整数でなければなりません。タグユニットを含むヘッダーフィールドが指定されている場合、音声出力は、タグに到達するか、SPEAK要求が完了するかのいずれか早い方まで続きます。このヘッダーフィールドは、音声データから話す長さを示すためにSPEAK要求で指定される場合があり、SPEAK要求が開始する音声のポイントに関連しています。サポートされるさまざまな音声長単位は、シンセサイザの実装に依存します。サーバーが指定されたユニットをサポートしない場合、サーバーは409 "Unsupported Header Field Value"のステータスコードで応答する必要があります。
speak-length = "Speak-Length" ":" positive-length-value CRLF
speak-length = "Speak-Length" "："正の長さの値CRLF
positive-length-value = positive-speech-length / text-speech-length
正の長さの値=正のスピーチの長さ/テキストのスピーチの長さ
text-speech-length = 1*UTFCHAR SP "Tag"
positive-speech-length = 1*19DIGIT SP numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
This header field is used to indicate whether a lexicon has to be loaded or unloaded. The value "true" means to load the lexicon if not already loaded, and the value "false" means to unload the lexicon if it is loaded. The default value for this header field is "true". This header field MAY be specified in a DEFINE-LEXICON method.
このヘッダーフィールドは、レキシコンをロードまたはアンロードする必要があるかどうかを示すために使用されます。値「true」は、まだロードされていない場合にレキシコンをロードすることを意味し、値「false」は、ロードされている場合にレキシコンをアンロードすることを意味します。このヘッダーフィールドのデフォルト値は「true」です。このヘッダーフィールドは、DEFINE-LEXICONメソッドで指定される場合があります。
load-lexicon = "Load-Lexicon" ":" BOOLEAN CRLF
load-lexicon = "Load-Lexicon" "：" BOOLEAN CRLF
This header field is used to specify a list of active pronunciation lexicon URIs and the search order among the active lexicons. Lexicons specified within the SSML document take precedence over the lexicons specified in this header field. This header field MAY be specified in the SPEAK, SET-PARAMS, and GET-PARAMS methods.
このヘッダーフィールドは、アクティブな発音辞書URIのリストと、アクティブな辞書間の検索順序を指定するために使用されます。 SSMLドキュメント内で指定されたレキシコンは、このヘッダーフィールドで指定されたレキシコンよりも優先されます。このヘッダーフィールドは、SPEAK、SET-PARAMS、およびGET-PARAMSメソッドで指定される場合があります。
lexicon-search-order = "Lexicon-Search-Order" ":"
"<" absoluteURI ">" *(" " "<" absoluteURI ">") CRLF
A synthesizer message can contain additional information associated with the Request, Response, or Event in its message body.
シンセサイザメッセージのメッセージ本文には、要求、応答、またはイベントに関連する追加情報を含めることができます。
Marked-up text for the synthesizer to speak is specified as a typed media entity in the message body. The speech data to be spoken by the synthesizer can be specified inline by embedding the data in the message body or by reference by providing a URI for accessing the data. In either case, the data and the format used to markup the speech needs to be of a content type supported by the server.
シンセサイザが話すためのマークアップされたテキストは、メッセージ本文の型付きメディアエンティティとして指定されます。シンセサイザが話す音声データは、メッセージ本文にデータを埋め込むか、データにアクセスするためのURIを指定して参照することにより、インラインで指定できます。どちらの場合も、スピーチのマークアップに使用されるデータと形式は、サーバーでサポートされているコンテンツタイプである必要があります。
All MRCPv2 servers containing synthesizer resources MUST support both plain text speech data and W3C's Speech Synthesis Markup Language [W3C.REC-speech-synthesis-20040907] and hence MUST support the media types 'text/plain' and 'application/ssml+xml'. Other formats MAY be supported.
シンセサイザリソースを含むすべてのMRCPv2サーバーは、プレーンテキストの音声データとW3Cの音声合成マークアップ言語[W3C.REC-speech-synthesis-20040907]の両方をサポートする必要があるため、メディアタイプ「text / plain」と「application / ssml + xml」をサポートする必要があります。他のフォーマットはサポートされるかもしれません。
If the speech data is to be fetched by URI reference, the media type 'text/uri-list' (see RFC 2483 [RFC2483]) is used to indicate one or more URIs that, when dereferenced, will contain the content to be spoken. If a list of speech URIs is specified, the resource MUST speak the speech data provided by each URI in the order in which the URIs are specified in the content.
音声データがURI参照でフェッチされる場合、メディアタイプ「text / uri-list」（RFC 2483 [RFC2483]を参照）を使用して、逆参照されたときに話されるコンテンツが含まれる1つ以上のURIを示します。 。スピーチURIのリストが指定されている場合、リソースは、コンテンツでURIが指定されている順序で、各URIによって提供されるスピーチデータを話す必要があります。
MRCPv2 clients and servers MUST support the 'multipart/mixed' media type. This is the appropriate media type to use when providing a mix of URI and inline speech data. Embedded within the multipart content block, there MAY be content for the 'text/uri-list', 'application/ ssml+xml', and/or 'text/plain' media types. The character set and encoding used in the speech data is specified according to standard media type definitions. The multipart content MAY also contain actual audio data. Clients may have recorded audio clips stored in memory or on a local device and wish to play it as part of the SPEAK request. The audio portions MAY be sent by the client as part of the multipart content block. This audio is referenced in the speech markup data that is another part in the multipart content block according to the 'multipart/mixed' media type specification.
MRCPv2クライアントとサーバーは、「マルチパート/混合」メディアタイプをサポートする必要があります。これは、URIとインライン音声データの組み合わせを提供するときに使用する適切なメディアタイプです。マルチパートコンテンツブロック内に埋め込まれた、「text / uri-list」、「application / ssml + xml」、「text / plain」メディアタイプのコンテンツが存在する場合があります。音声データで使用される文字セットとエンコーディングは、標準のメディアタイプ定義に従って指定されます。マルチパートコンテンツには、実際のオーディオデータも含まれる場合があります。クライアントは、メモリまたはローカルデバイスに保存されたオーディオクリップを録音していて、それをSPEAK要求の一部として再生したい場合があります。オーディオ部分は、マルチパートコンテンツブロックの一部としてクライアントから送信される場合があります。このオーディオは、「マルチパート/混合」メディアタイプ仕様に従ってマルチパートコンテンツブロックの別のパートであるスピーチマークアップデータで参照されます。
Content-Type:text/uri-list Content-Length:...
Content-Type：text / uri-list Content-Length：...
http://www.example.com/ASR-Introduction.ssml
http://www.example.com/ASR-Document-Part1.ssml
http://www.example.com/ASR-Document-Part2.ssml
http://www.example.com/ASR-Conclusion.ssml
URI List Example
URIリストの例
Content-Type:application/ssml+xml Content-Length:...
Content-Type：application / ssml + xml Content-Length：...
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Aldine Turnbet
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
SSML Example
SSMLの例
Content-Type:multipart/mixed; boundary="break"
--break Content-Type:text/uri-list Content-Length:...
--break Content-Type：text / uri-list Content-Length：...
http://www.example.com/ASR-Introduction.ssml
http://www.example.com/ASR-Document-Part1.ssml
http://www.example.com/ASR-Document-Part2.ssml
http://www.example.com/ASR-Conclusion.ssml
--break Content-Type:application/ssml+xml Content-Length:...
--break Content-Type：application / ssml + xml Content-Length：...
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
--break--
Multipart Example
マルチパートの例
Synthesizer lexicon data from the client to the server can be provided inline or by reference. Either way, they are carried as typed media in the message body of the MRCPv2 request message (see Section 8.14).
クライアントからサーバーへのシンセサイザ辞書データは、インラインまたは参照によって提供できます。どちらの場合も、それらはMRCPv2要求メッセージのメッセージ本文の型付きメディアとして運ばれます（セクション8.14を参照）。
When a lexicon is specified inline in the message, the client MUST provide a Content-ID for that lexicon as part of the content header fields. The server MUST store the lexicon associated with that Content-ID for the duration of the session. A stored lexicon can be overwritten by defining a new lexicon with the same Content-ID.
メッセージ内でレキシコンがインラインで指定されている場合、クライアントは、コンテンツヘッダーフィールドの一部としてそのレキシコンのContent-IDを提供する必要があります。サーバーは、セッションの期間中、そのContent-IDに関連付けられたレキシコンを保存する必要があります。保存されたレキシコンは、同じContent-IDで新しいレキシコンを定義することによって上書きできます。
Lexicons that have been associated with a Content-ID can be referenced through the 'session' URI scheme (see Section 13.6).
Content-IDに関連付けられているレキシコンは、「セッション」URIスキームを通じて参照できます（セクション13.6を参照）。
If lexicon data is specified by external URI reference, the media type 'text/uri-list' (see RFC 2483 [RFC2483] ) is used to list the one or more URIs that may be dereferenced to obtain the lexicon data. All MRCPv2 servers MUST support the "http" and "https" URI access mechanisms, and MAY support other mechanisms.
辞書データが外部URI参照で指定されている場合、メディアタイプ 'text / uri-list'（RFC 2483 [RFC2483]を参照）を使用して、辞書データを取得するために逆参照できる1つ以上のURIをリストします。すべてのMRCPv2サーバーは「http」および「https」URIアクセスメカニズムをサポートする必要があり、他のメカニズムをサポートする場合があります（MAY）。
If the data in the message body consists of a mix of URI and inline lexicon data, the 'multipart/mixed' media type is used. The character set and encoding used in the lexicon data may be specified according to standard media type definitions.
メッセージ本文のデータがURIとインライン辞書データの組み合わせで構成されている場合は、「multipart / mixed」メディアタイプが使用されます。辞書データで使用される文字セットとエンコーディングは、標準のメディアタイプ定義に従って指定できます。
The SPEAK request provides the synthesizer resource with the speech text and initiates speech synthesis and streaming. The SPEAK method MAY carry voice and prosody header fields that alter the behavior of the voice being synthesized, as well as a typed media message body containing the actual marked-up text to be spoken.
SPEAKリクエストは、シンセサイザリソースに音声テキストを提供し、音声合成とストリーミングを開始します。 SPEAKメソッドは、合成される音声の動作を変更する音声と韻律のヘッダーフィールド、および発声される実際のマークアップされたテキストを含む型付きのメディアメッセージ本文を伝送する場合があります。
The SPEAK method implementation MUST do a fetch of all external URIs that are part of that operation. If caching is implemented, this URI fetching MUST conform to the cache-control hints and parameter header fields associated with the method in deciding whether it is to be fetched from cache or from the external server. If these hints/ parameters are not specified in the method, the values set for the session using SET-PARAMS/GET-PARAMS apply. If it was not set for the session, their default values apply.
SPEAKメソッドの実装は、その操作の一部であるすべての外部URIのフェッチを実行する必要があります。キャッシングが実装されている場合、このURIフェッチは、メソッドをキャッシュからフェッチするか、外部サーバーからフェッチするかを決定する際に、メソッドに関連付けられたキャッシュコントロールヒントおよびパラメーターヘッダーフィールドに準拠する必要があります。これらのヒント/パラメーターがメソッドで指定されていない場合、SET-PARAMS / GET-PARAMSを使用してセッションに設定された値が適用されます。セッションに設定されていない場合は、デフォルト値が適用されます。
When applying voice parameters, there are three levels of precedence. 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 that apply for that SPEAK request only, followed by the session default values that can be set using the SET-PARAMS request and apply for subsequent methods invoked during the session.
音声パラメータを適用する場合、優先順位には3つのレベルがあります。最高の優先順位は、スピーチマークアップテキスト内で指定されたものであり、その後にSPEAK要求のヘッダーフィールドで指定されたもの、したがってそのSPEAK要求にのみ適用され、その後にSET-PARAMS要求を使用して設定できるセッションのデフォルト値が続きます。そして、セッション中に呼び出される後続のメソッドに適用します。
If the resource was idle at the time the SPEAK request arrived at the server and the SPEAK method is being actively processed, the resource responds immediately with a success status code and a request-state of IN-PROGRESS.
SPEAK要求がサーバーに到着したときにリソースがアイドル状態で、SPEAKメソッドがアクティブに処理されている場合、リソースは成功ステータスコードと要求状態IN-PROGRESSで即座に応答します。
If the resource is in the speaking or paused state when the SPEAK method arrives at the server, i.e., it is in the middle of processing a previous SPEAK request, the status returns success with a request-state of PENDING. The server places the SPEAK request in the synthesizer resource request queue. The request queue operates strictly FIFO: requests are processed serially in order of receipt. If the current SPEAK fails, all SPEAK methods in the pending queue are cancelled and each generates a SPEAK-COMPLETE event with a Completion-Cause of "cancelled".
SPEAKメソッドがサーバーに到着したときにリソースが発話状態または一時停止状態にある場合、つまり、前のSPEAK要求の処理中である場合、要求はPENDINGの要求状態で成功を返します。サーバーは、SPEAK要求をシンセサイザリソース要求キューに配置します。リクエストキューは厳密にFIFOで動作します。リクエストは受信順にシリアルに処理されます。現在のSPEAKが失敗した場合、保留中のキュー内のすべてのSPEAKメソッドがキャンセルされ、それぞれが「キャンセル」のCompletion-Causeを持つSPEAK-COMPLETEイベントを生成します。
For the synthesizer resource, SPEAK is the only method that can return a request-state of IN-PROGRESS or PENDING. When the text has been synthesized and played into the media stream, the resource issues a SPEAK-COMPLETE event with the request-id of the SPEAK request and a request-state of COMPLETE.
シンセサイザリソースの場合、SPEAKは、IN-PROGRESSまたはPENDINGの要求状態を返すことができる唯一のメソッドです。テキストが合成されてメディアストリームに再生されると、リソースはSPEAK要求のrequest-idとCOMPLETEのrequest-stateを含むSPEAK-COMPLETEイベントを発行します。
C->S: MRCP/2.0 ... SPEAK 543257 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-Age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543257 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-Age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams and arrived at
<break/>
<say-as interpret-as="vxml:time">0342p</say-as>.
</s>
<s>The subject is
<prosody rate="-20%">ski trip</prosody>
</s>
</p>
</speak>
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206027059
S->C: MRCP/2.0 ... SPEAK-COMPLETE 543257 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Completion-Cause:000 normal
Speech-Marker:timestamp=857206027059
SPEAK Example
SPEAKの例
The STOP method from the client to the server tells the synthesizer 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 status-code of 200 "Success". If no Active-Request-Id-List header field is sent in the STOP request, the server terminates all outstanding SPEAK requests.
STOP要求は、Active-Request-Id-Listヘッダーフィールドと共に送信され、キューにある可能性のあるゼロ以上の特定のSPEAK要求を停止し、200 "成功"の応答ステータスコードを返します。 STOP要求でActive-Request-Id-Listヘッダーフィールドが送信されない場合、サーバーはすべての未処理のSPEAK要求を終了します。
If a STOP request successfully terminated one or more PENDING or IN-PROGRESS SPEAK requests, then the response MUST contain an Active-Request-Id-List header field enumerating the SPEAK request-ids that were terminated. Otherwise, there is no Active-Request-Id-List header field in the response. No SPEAK-COMPLETE events are sent for such terminated requests.
STOP要求が1つ以上のPENDINGまたはIN-PROGRESS SPEAK要求を正常に終了した場合、応答には、終了したSPEAK要求IDを列挙するActive-Request-Id-Listヘッダーフィールドが含まれている必要があります。それ以外の場合、応答にActive-Request-Id-Listヘッダーフィールドはありません。そのような終了した要求に対してSPEAK-COMPLETEイベントは送信されません。
If a SPEAK request that was IN-PROGRESS and speaking was stopped, the next pending SPEAK request, if any, becomes IN-PROGRESS at the resource and enters the speaking state.
IN-PROGRESSであり、発言していたSPEAK要求が停止した場合、次の保留中のSPEAK要求があれば、リソースでIN-PROGRESSになり、発言状態に入ります。
If a SPEAK request that was IN-PROGRESS and paused was stopped, the next pending SPEAK request, if any, becomes IN-PROGRESS and enters the paused state.
IN-PROGRESSで一時停止していたSPEAKリクエストが停止した場合、次の保留中のSPEAKリクエストがあれば、それはIN-PROGRESSになり、一時停止状態になります。
C->S: MRCP/2.0 ... SPEAK 543258 Channel-Identifier:32AECB23433802@speechsynth Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543258 Channel-Identifier：32AECB23433802 @ speechsynth Content-Type：application / ssml + xml Content-Length：...
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams and arrived at
<break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is
<prosody rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206027059
C->S: MRCP/2.0 ... STOP 543259
Channel-Identifier:32AECB23433802@speechsynth
S->C: MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
Speech-Marker:timestamp=857206039059
STOP Example
STOPの例
The BARGE-IN-OCCURRED method, when used with the synthesizer resource, provides a client that has detected a barge-in-able event a means to communicate the occurrence of the event to the synthesizer resource.
BARGE-IN-OCCURREDメソッドをシンセサイザリソースで使用すると、割り込み可能イベントを検出したクライアントに、イベントの発生をシンセサイザリソースに通知する手段が提供されます。
This method is useful in two scenarios:
この方法は、次の2つのシナリオで役立ちます。
1. The client has detected DTMF digits in the input media or some other barge-in-able event and wants to communicate that to the synthesizer resource.
1. クライアントは、入力メディアまたは他の割り込み可能なイベントでDTMFディジットを検出し、それをシンセサイザリソースに伝えたいと考えています。
2. The recognizer resource and the synthesizer resource are in different servers. In this case, the client acts as an intermediary for the two servers. It receives an event from the recognition resource and sends a BARGE-IN-OCCURRED request 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. レコグナイザリソースとシンセサイザリソースは別のサーバーにあります。この場合、クライアントは2つのサーバーの仲介者として機能します。認識リソースからイベントを受け取り、BARGE-IN-OCCURREDリクエストをシンセサイザに送信します。このような場合、BARGE-IN-OCCURREDメソッドには、元のイベントを生成するリソースから受信したProxy-Sync-Idヘッダーフィールドも含まれます。
If a SPEAK request is active with kill-on-barge-in enabled (see Section 8.4.2), and the BARGE-IN-OCCURRED event is received, the synthesizer MUST immediately stop streaming out audio. It MUST also terminate any speech requests queued behind the current active one, irrespective of whether or not they have barge-in enabled. If a barge-in-able SPEAK request was playing and it was terminated, the response MUST contain an Active-Request-Id-List header field listing the request-ids of all SPEAK requests that were terminated. The server generates no SPEAK-COMPLETE events for these requests.
SPEAK要求がkill-on-barge-inを有効にしてアクティブになっている場合（セクション8.4.2を参照）、BARGE-IN-OCCURREDイベントを受信すると、シンセサイザはオーディオのストリーミングをただちに停止する必要があります。また、割り込みが有効になっているかどうかに関係なく、現在アクティブなリクエストの後ろにキューイングされているすべての音声リクエストを終了する必要があります。割り込み可能なSPEAK要求が再生され、それが終了した場合、応答には、終了したすべてのSPEAK要求の要求IDをリストするActive-Request-Id-Listヘッダーフィールドが含まれている必要があります。サーバーは、これらの要求に対してSPEAK-COMPLETEイベントを生成しません。
If there were no SPEAK requests terminated by the synthesizer resource as a result of the BARGE-IN-OCCURRED method, the server MUST respond to the BARGE-IN-OCCURRED with a status-code of 200 "Success", and the response MUST NOT contain an Active-Request-Id-List header field.
BARGE-IN-OCCURREDメソッドの結果としてシンセサイザリソースによって終了されたSPEAK要求がなかった場合、サーバーはステータスコード200の「成功」でBARGE-IN-OCCURREDに応答する必要があり、応答はActive-Request-Id-Listヘッダーフィールドが含まれています。
If the synthesizer and recognizer resources are part of the same MRCPv2 session, they can be optimized for a quicker kill-on-barge-in response if the recognizer and synthesizer interact directly. In these cases, the client MUST still react to a START-OF-INPUT event from the recognizer by invoking the BARGE-IN-OCCURRED method to the synthesizer. The client MUST invoke the BARGE-IN-OCCURRED if it has any outstanding requests to the synthesizer resource in either the PENDING or IN-PROGRESS state.
シンセサイザとレコグナイザのリソースが同じMRCPv2セッションの一部である場合、レコグナイザとシンセサイザが直接相互作用する場合は、これらを最適化して、割り込みのキルオン応答を高速化できます。これらの場合でも、クライアントは、シンセサイザーに対してBARGE-IN-OCCURREDメソッドを呼び出すことにより、認識エンジンからのSTART-OF-INPUTイベントに反応する必要があります。クライアントは、PENDINGまたはIN-PROGRESS状態のシンセサイザリソースに対する未処理の要求がある場合は、BARGE-IN-OCCURREDを呼び出す必要があります。
C->S: MRCP/2.0 ... SPEAK 543258 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-Age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543258 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-Age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams and arrived at
<break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is
<prosody rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206027059
C->S: MRCP/2.0 ... BARGE-IN-OCCURRED 543259
Channel-Identifier:32AECB23433802@speechsynth
Proxy-Sync-Id:987654321
S->C:MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
Speech-Marker:timestamp=857206039059
BARGE-IN-OCCURRED Example
割り込みが発生した例
The PAUSE method from the client to the server tells the synthesizer resource to pause speech output if it is speaking something. If a PAUSE method is issued on a session when a SPEAK is not active, the server MUST respond with a status-code of 402 "Method not valid in this state". If a PAUSE method is issued on a session when a SPEAK is active and paused, the server MUST respond with a status-code of 200 "Success". If a SPEAK request was active, the server MUST return an Active-Request-Id-List header field whose value contains the request-id of the SPEAK request that was paused.
クライアントからサーバーへのPAUSEメソッドは、何かを話している場合、音声出力を一時停止するようにシンセサイザリソースに指示します。 SPEAKがアクティブでないときにセッションでPAUSEメソッドが発行された場合、サーバーはステータスコード402「この状態ではメソッドが無効」で応答する必要があります。 SPEAKがアクティブで一時停止しているときにセッションでPAUSEメソッドが発行された場合、サーバーはステータスコード200「成功」で応答する必要があります。 SPEAKリクエストがアクティブだった場合、サーバーは、一時停止したSPEAKリクエストのリクエストIDを値に含むActive-Request-Id-Listヘッダーフィールドを返さなければなりません（MUST）。
C->S: MRCP/2.0 ... SPEAK 543258 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-Age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543258 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-Age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams and arrived at
<break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is
<prosody rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206027059
C->S: MRCP/2.0 ... PAUSE 543259
Channel-Identifier:32AECB23433802@speechsynth
S->C: MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
PAUSE Example
一時停止の例
The RESUME method from the client to the server tells a paused synthesizer resource to resume speaking. If a RESUME request is issued on a session with no active SPEAK request, the server MUST respond with a status-code of 402 "Method not valid in this state". If a RESUME request is issued on a session with an active SPEAK request that is speaking (i.e., not paused), the server MUST respond with a status-code of 200 "Success". If a SPEAK request was paused, the server MUST return an Active-Request-Id-List header field whose value contains the request-id of the SPEAK request that was resumed.
クライアントからサーバーへのRESUMEメソッドは、一時停止されたシンセサイザリソースに発話を再開するように指示します。アクティブなSPEAK要求のないセッションでRESUME要求が発行された場合、サーバーはステータスコード402「この状態では無効なメソッド」で応答する必要があります。アクティブなSPEAK要求が発言している（つまり、一時停止されていない）セッションでRESUME要求が発行された場合、サーバーはステータスコード200の「成功」で応答する必要があります。 SPEAKリクエストが一時停止された場合、サーバーは、再開されたSPEAKリクエストのリクエストIDを値に含むActive-Request-Id-Listヘッダーフィールドを返さなければなりません（MUST）。
C->S: MRCP/2.0 ... SPEAK 543258 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543258 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams and arrived at
<break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is
<prosody rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS@speechsynth
Channel-Identifier:32AECB23433802
Speech-Marker:timestamp=857206027059
C->S: MRCP/2.0 ... PAUSE 543259
Channel-Identifier:32AECB23433802@speechsynth
S->C: MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
C->S: MRCP/2.0 ... RESUME 543260
Channel-Identifier:32AECB23433802@speechsynth
S->C: MRCP/2.0 ... 543260 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
RESUME Example
RESUMEの例
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 request the synthesizer to jump forward or backward in what it is speaking, change speaker rate, speaker parameters, etc. It affects only the currently IN-PROGRESS SPEAK request. Depending on the implementation and capability of the synthesizer resource, it may or may not support the various modifications indicated by header fields in the CONTROL request.
クライアントからサーバーへのCONTROLメソッドは、話しているシンセサイザに、その場で話している内容を変更するよう指示します。このメソッドは、発話中の前方または後方へのジャンプ、スピーカーレート、スピーカーパラメーターの変更などをシンセサイザに要求するために使用されます。これは、現在進行中のSPEAKリクエストにのみ影響します。シンセサイザリソースの実装と機能に応じて、CONTROLリクエストのヘッダーフィールドで示されるさまざまな変更をサポートする場合とサポートしない場合があります。
When a client invokes a CONTROL method to jump forward and the operation goes beyond the end of the active SPEAK method's text, the CONTROL request still succeeds. The active SPEAK request completes and returns a SPEAK-COMPLETE event following the response to the CONTROL method. If there are more SPEAK requests in the queue, the synthesizer resource starts at the beginning of the next SPEAK request in the queue.
クライアントがCONTROLメソッドを呼び出して前方にジャンプし、操作がアクティブなSPEAKメソッドのテキストの終わりを超えても、CONTROL要求は引き続き成功します。アクティブなSPEAK要求が完了し、CONTROLメソッドへの応答に続いてSPEAK-COMPLETEイベントを返します。キューにさらにSPEAK要求がある場合、シンセサイザリソースは、キュー内の次のSPEAK要求の先頭から開始されます。
When a client invokes a CONTROL method to jump backward and the operation jumps to the beginning or beyond the beginning of the speech data of the active SPEAK method, the CONTROL request still succeeds. The response to the CONTROL request contains the speak-restart header field, and the active SPEAK request restarts from the beginning of its speech data.
クライアントがCONTROLメソッドを呼び出して後方にジャンプし、操作がアクティブなSPEAKメソッドの音声データの先頭または先頭を超えてジャンプしても、CONTROL要求は引き続き成功します。 CONTROL要求への応答には、speak-restartヘッダーフィールドが含まれており、アクティブなSPEAK要求は、音声データの先頭から再開されます。
These two behaviors can be used to rewind or fast-forward across multiple speech requests, if the client wants to break up a speech markup text into multiple SPEAK requests.
クライアントがスピーチマークアップテキストを複数のSPEAKリクエストに分割したい場合、これら2つの動作を使用して、複数のスピーチリクエストを巻き戻したり早送りしたりできます。
If a SPEAK request was active when the CONTROL method was received, the server MUST return an Active-Request-Id-List header field containing the request-id of the SPEAK request that was active.
CONTROLメソッドを受信したときにSPEAKリクエストがアクティブだった場合、サーバーはアクティブだったSPEAKリクエストのリクエストIDを含むActive-Request-Id-Listヘッダーフィールドを返さなければなりません（MUST）。
C->S: MRCP/2.0 ... SPEAK 543258 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543258 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857205016059
C->S: MRCP/2.0 ... CONTROL 543259
Channel-Identifier:32AECB23433802@speechsynth
Prosody-rate:fast
S->C: MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
Speech-Marker:timestamp=857206027059
C->S: MRCP/2.0 ... CONTROL 543260
Channel-Identifier:32AECB23433802@speechsynth
Jump-Size:-15 Words
S->C: MRCP/2.0 ... 543260 200 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Active-Request-Id-List:543258
Speech-Marker:timestamp=857206039059
CONTROL Example
CONTROLの例
This is an Event message from the synthesizer resource to the client that indicates the corresponding SPEAK request was completed. The request-id field matches the request-id of the SPEAK request that initiated the speech that just completed. The request-state field is set to COMPLETE by the server, indicating that this is the last event with the corresponding request-id. 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, kill-on-barge-in, etc.
これは、対応するSPEAK要求が完了したことを示す、シンセサイザリソースからクライアントへのイベントメッセージです。 request-idフィールドは、完了したばかりの音声を開始したSPEAK要求のrequest-idと一致します。 request-stateフィールドはサーバーによってCOMPLETEに設定され、これが対応するrequest-idを持つ最後のイベントであることを示します。 Completion-Causeヘッダーフィールドは、正常に完了したSPEAKや、エラー、kill-on-barge-inなどが原因で、リクエストが完了したステータスと理由に関連する原因コードを指定します。
C->S: MRCP/2.0 ... SPEAK 543260 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543260 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<s>The subject is
<prosody rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C: MRCP/2.0 ... 543260 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206027059
S->C: MRCP/2.0 ... SPEAK-COMPLETE 543260 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Completion-Cause:000 normal
Speech-Marker:timestamp=857206039059
SPEAK-COMPLETE Example
SPEAK-COMPLETEの例
This is an event generated by the synthesizer resource to the client when the synthesizer encounters a marker tag in the speech markup it is currently processing. The value of the request-id field MUST match that of the corresponding SPEAK request. The request-state field MUST have the value "IN-PROGRESS" as the speech is still not complete. The value of the speech marker tag hit, describing where the synthesizer is in the speech markup, MUST be returned in the Speech-Marker header field, along with an NTP timestamp indicating the instant in the output speech stream that the marker was encountered. The SPEECH-MARKER event MUST also be generated with a null marker value and output NTP timestamp when a SPEAK request in Pending-State (i.e., in the queue) changes state to IN-PROGRESS and starts speaking. The NTP timestamp MUST be synchronized with the RTP timestamp used to generate the speech stream through standard RTCP machinery.
これは、シンセサイザが現在処理しているスピーチマークアップでマーカータグに遭遇したときに、シンセサイザリソースによってクライアントに生成されるイベントです。 request-idフィールドの値は、対応するSPEAK要求の値と一致する必要があります。スピーチがまだ完了していないため、request-stateフィールドの値は「IN-PROGRESS」である必要があります。音声マーカータグヒットの値は、シンセサイザが音声マークアップのどこにあるかを示し、マーカーが検出された出力音声ストリームの瞬間を示すNTPタイムスタンプとともに、Speech-Markerヘッダーフィールドに返される必要があります。 SPEECH-MARKERイベントは、Nendingマーカー値で生成され、Pending-State（つまり、キュー内）のSPEAKリクエストが状態をIN-PROGRESSに変更して発言を開始したときにNTPタイムスタンプを出力する必要があります。 NTPタイムスタンプは、標準のRTCP機構を介して音声ストリームを生成するために使用されるRTPタイムスタンプと同期する必要があります。
C->S: MRCP/2.0 ... SPEAK 543261 Channel-Identifier:32AECB23433802@speechsynth Voice-gender:neutral Voice-age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543261 Channel-Identifier：32AECB23433802 @ speechsynth Voice-gender：neutral Voice-age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：.. 。
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
and arrived at <break/>
<say-as interpret-as="vxml:time">0342p</say-as>.</s>
<mark name="here"/>
<s>The subject is
<prosody rate="-20%">ski trip</prosody>
</s>
<mark name="ANSWER"/>
</p>
</speak>
S->C: MRCP/2.0 ... 543261 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857205015059
S->C: MRCP/2.0 ... SPEECH-MARKER 543261 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206027059;here
S->C: MRCP/2.0 ... SPEECH-MARKER 543261 IN-PROGRESS
Channel-Identifier:32AECB23433802@speechsynth
Speech-Marker:timestamp=857206039059;ANSWER
S->C: MRCP/2.0 ... SPEAK-COMPLETE 543261 COMPLETE
Channel-Identifier:32AECB23433802@speechsynth
Completion-Cause:000 normal
Speech-Marker:timestamp=857207689259;ANSWER
SPEECH-MARKER Example
スピーチマーカーの例
The DEFINE-LEXICON method, from the client to the server, provides a lexicon and tells the server to load or unload the lexicon (see Section 8.4.16). The media type of the lexicon is provided in the Content-Type header (see Section 8.5.2). One such media type is "application/pls+xml" for the Pronunciation Lexicon Specification (PLS) [W3C.REC-pronunciation-lexicon-20081014] [RFC4267].
クライアントからサーバーへのDEFINE-LEXICONメソッドは、レキシコンを提供し、レキシコンをロードまたはアンロードするようサーバーに指示します（8.4.16項を参照）。レキシコンのメディアタイプは、Content-Typeヘッダーで提供されます（8.5.2項を参照）。そのようなメディアタイプの1つは、発音辞書仕様（PLS）の「application / pls + xml」です[W3C.REC-pronunciation-lexicon-20081014] [RFC4267]。
If the server resource is in the speaking or paused state, the server MUST respond with a failure status-code of 402 "Method not valid in this state".
サーバーリソースが発言中または一時停止の状態にある場合、サーバーは障害ステータスコード402「この状態ではメソッドが無効」で応答する必要があります。
If the resource is in the idle state and is able to successfully load/unload the lexicon, the status MUST return a 200 "Success" status-code and the request-state MUST be COMPLETE.
リソースがアイドル状態にあり、レキシコンを正常にロード/アンロードできる場合、ステータスは200 "成功"ステータスコードを返さなければならず（MUST）、リクエスト状態はCOMPLETEでなければなりません。
If the synthesizer could not define the lexicon for some reason, for example, because the download failed or the lexicon was in an unsupported form, the server MUST respond with a failure status-code of 407 and a Completion-Cause header field describing the failure reason.
シンセサイザが何らかの理由でレキシコンを定義できなかった場合、たとえば、ダウンロードが失敗したか、レキシコンがサポートされていない形式であった場合、サーバーは失敗ステータスコード407と失敗を説明するCompletion-Causeヘッダーフィールドで応答する必要があります理由。
The speech recognizer resource receives an incoming voice stream and provides the client with an interpretation of what was spoken in textual form.
音声認識リソースは着信音声ストリームを受け取り、クライアントにテキスト形式で話された内容の解釈を提供します。
The recognizer resource is controlled by MRCPv2 requests from the client. The recognizer resource can both respond to these requests and generate asynchronous events to the client to indicate conditions of interest during the processing of the method.
レコグナイザリソースは、クライアントからのMRCPv2要求によって制御されます。認識リソースは、これらの要求に応答することも、クライアントに非同期イベントを生成して、メソッドの処理中に対象の状態を示すこともできます。
This section applies to the following resource types.
このセクションは、次のリソースタイプに適用されます。
1. speechrecog
1. スピーチ
2. dtmfrecog
2. dtmfrecog
The difference between the above two resources is in their level of support for recognition grammars. The "dtmfrecog" resource type is capable of recognizing only DTMF digits and hence accepts only DTMF grammars. It only generates barge-in for DTMF inputs and ignores speech. The "speechrecog" resource type can recognize regular speech as well as DTMF digits and hence MUST support grammars describing either speech or DTMF. This resource generates barge-in events for speech and/or DTMF. By analyzing the grammars that are activated by the RECOGNIZE method, it determines if a barge-in should occur for speech and/or DTMF. When the recognizer decides it needs to generate a barge-in, it also generates a START-OF-INPUT event to the client. The recognizer resource MAY support recognition in the normal or hotword modes or both (although note that a single "speechrecog" resource does not perform normal and hotword mode recognition simultaneously). For implementations where a single recognizer resource does not support both modes, or simultaneous normal and hotword recognition is desired, the two modes can be invoked through separate resources allocated to the same SIP dialog (with different MRCP session identifiers) and share the RTP audio feed.
上記の2つのリソースの違いは、認識文法のサポートのレベルにあります。 「dtmfrecog」リソースタイプは、DTMFディジットのみを認識できるため、DTMF文法のみを受け入れます。 DTMF入力に対して割り込みのみを生成し、音声を無視します。 「speechrecog」リソースタイプは、通常の音声とDTMFディジットを認識できるため、音声またはDTMFのいずれかを記述する文法をサポートする必要があります。このリソースは、音声またはDTMF、あるいはその両方の割り込みイベントを生成します。 RECOGNIZEメソッドによってアクティブ化される文法を分析することにより、音声やDTMFに対して割り込みが発生するかどうかを判断します。認識機能が割り込みを生成する必要があると判断すると、クライアントへのSTART-OF-INPUTイベントも生成します。レコグナイザリソースは、ノーマルモードまたはホットワードモード、あるいはその両方での認識をサポートする場合があります（ただし、単一の「speechrecog」リソースはノーマルモードとホットワードモードの認識を同時に実行しないことに注意してください）。単一の認識リソースが両方のモードをサポートしていない、または通常と注目ワードの同時認識が必要な実装の場合、2つのモードは、（異なるMRCPセッション識別子を使用して）同じSIPダイアログに割り当てられた個別のリソースから呼び出し、RTPオーディオフィードを共有できます。 。
The capabilities of the recognizer resource are enumerated below:
レコグナイザリソースの機能を以下に列挙します。
Normal Mode Recognition Normal mode recognition tries to match all of the speech or DTMF against the grammar and returns a no-match status if the input fails to match or the method times out.
通常モード認識通常モード認識は、すべての音声またはDTMFを文法と照合しようとし、入力が一致しないか、メソッドがタイムアウトした場合、不一致ステータスを返します。
Hotword Mode Recognition Hotword mode is where the recognizer looks for a match against specific speech grammar or DTMF sequence and ignores speech or DTMF that does not match. The recognition completes only if there is a successful match of grammar, if the client cancels the request, or if there is a non-input or recognition timeout.
ホットワードモードの認識ホットワードモードでは、認識機能が特定の音声文法またはDTMFシーケンスに対する一致を探し、一致しない音声またはDTMFを無視します。認識は、文法の一致が成功した場合、クライアントが要求をキャンセルした場合、または非入力または認識タイムアウトがある場合にのみ完了します。
Voice Enrolled Grammars A recognizer resource MAY optionally support Voice Enrolled Grammars. With this functionality, enrollment is performed using a person's voice. For example, a list of contacts can be created and maintained by recording the person's names using the caller's voice. This technique is sometimes also called speaker-dependent recognition.
Voice Enrolled Grammarsレコグナイザリソースは、オプションでVoice Enrolled Grammarsをサポートする場合があります。この機能により、登録は人の声を使用して実行されます。たとえば、発信者の声を使用して人の名前を録音することにより、連絡先のリストを作成および維持できます。この手法は、話者依存の認識とも呼ばれます。
Interpretation A recognizer resource MAY be employed strictly for its natural language interpretation capabilities by supplying it with a text string as input instead of speech. In this mode, the resource takes text as input and produces an "interpretation" of the input according to the supplied grammar.
解釈認識リソースは、音声ではなく入力としてテキスト文字列を提供することにより、自然言語解釈機能に厳密に使用できます。このモードでは、リソースはテキストを入力として受け取り、提供された文法に従って入力の「解釈」を生成します。
Voice enrollment has the concept of an enrollment session. A session to add a new phrase to a personal grammar involves the initial enrollment followed by a repeat of enough utterances before committing the new phrase to the personal grammar. Each time an utterance is recorded, it is compared for similarity with the other samples and a clash test is performed against other entries in the personal grammar to ensure there are no similar and confusable entries.
音声登録には、登録セッションの概念があります。新しいフレーズを個人の文法に追加するセッションでは、最初の登録に続いて、新しいフレーズを個人の文法にコミットする前に十分な発話を繰り返します。発話が記録されるたびに、他のサンプルとの類似性が比較され、個人の文法の他のエントリに対してクラッシュテストが実行され、類似した混乱のないエントリがないことを確認します。
Enrollment is done using a recognizer resource. Controlling which utterances are to be considered for enrollment of a new phrase is done by setting a header field (see Section 9.4.39) in the Recognize request.
登録は、認識リソースを使用して行われます。新しいフレーズの登録でどの発話が考慮されるかを制御するには、Recognizeリクエストでヘッダーフィールド（9.4.39を参照）を設定します。
Interpretation is accomplished through the INTERPRET method (Section 9.20) and the Interpret-Text header field (Section 9.4.30).
解釈は、INTERPRETメソッド（セクション9.20）およびInterpret-Textヘッダーフィールド（セクション9.4.30）を介して行われます。
The recognizer resource maintains a state machine to process MRCPv2 requests from the client.
レコグナイザリソースは、クライアントからのMRCPv2要求を処理するステートマシンを維持します。
Idle Recognizing Recognized
State State State
| | |
|---------RECOGNIZE---->|---RECOGNITION-COMPLETE-->|
|<------STOP------------|<-----RECOGNIZE-----------|
| | |
| |--------| |-----------|
| START-OF-INPUT | GET-RESULT |
| |------->| |---------->|
|------------| | |
| DEFINE-GRAMMAR |----------| |
|<-----------| | START-INPUT-TIMERS |
| |<---------| |
|------| | |
| INTERPRET | |
|<-----| |------| |
| | RECOGNIZE |
|-------| |<-----| |
| STOP |
|<------| |
|<-------------------STOP--------------------------|
|<-------------------DEFINE-GRAMMAR----------------|
Recognizer State Machine
レコグナイザーステートマシン
If a recognizer resource supports voice enrolled grammars, starting an enrollment session does not change the state of the recognizer resource. Once an enrollment session is started, then utterances are enrolled by calling the RECOGNIZE method repeatedly. The state of the speech recognizer resource goes from IDLE to RECOGNIZING state each time RECOGNIZE is called.
認識リソースが音声登録済みの文法をサポートしている場合、登録セッションを開始しても認識リソースの状態は変更されません。登録セッションが開始されると、RECOGNIZEメソッドを繰り返し呼び出して発話が登録されます。音声認識リソースの状態は、RECOGNIZEが呼び出されるたびにIDLE状態からRECOGNIZING状態になります。
The recognizer supports the following methods.
レコグナイザは次のメソッドをサポートしています。
recognizer-method = recog-only-method / enrollment-method
レコグナイザメソッド= recog-only-method / enrollment-method
recog-only-method = "DEFINE-GRAMMAR"
/ "RECOGNIZE"
/ "INTERPRET"
/ "GET-RESULT"
/ "START-INPUT-TIMERS"
/ "STOP"
It is OPTIONAL for a recognizer resource to support voice enrolled grammars. If the recognizer resource does support voice enrolled grammars, it MUST support the following methods.
認識リソースが音声登録済み文法をサポートすることはオプションです。レコグナイザリソースが音声登録済みの文法をサポートする場合、次のメソッドをサポートする必要があります。
enrollment-method = "START-PHRASE-ENROLLMENT"
/ "ENROLLMENT-ROLLBACK"
/ "END-PHRASE-ENROLLMENT"
/ "MODIFY-PHRASE"
/ "DELETE-PHRASE"
The recognizer can generate the following events.
認識エンジンは、次のイベントを生成できます。
recognizer-event = "START-OF-INPUT" / "RECOGNITION-COMPLETE" / "INTERPRETATION-COMPLETE"
レコグナイザイベント= "START-OF-INPUT" / "RECOGNITION-COMPLETE" / "INTERPRETATION-COMPLETE"
A recognizer message can contain header fields containing request options and information to augment the Method, Response, or Event message it is associated with.
認識メッセージには、関連付けられているメソッド、応答、またはイベントメッセージを補強するためのリクエストオプションと情報を含むヘッダーフィールドを含めることができます。
recognizer-header = recog-only-header / enrollment-header
レコグナイザヘッダー= recog-only-header / enrollment-header
recog-only-header = confidence-threshold
/ sensitivity-level
/ speed-vs-accuracy
/ n-best-list-length
/ no-input-timeout
/ input-type
/ recognition-timeout
/ waveform-uri
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ recognizer-context-block
/ start-input-timers
/ speech-complete-timeout
/ speech-incomplete-timeout
/ dtmf-interdigit-timeout
/ dtmf-term-timeout
/ dtmf-term-char
/ failed-uri
/ failed-uri-cause
/ save-waveform
/ media-type
/ new-audio-channel
/ speech-language
/ ver-buffer-utterance
/ recognition-mode
/ cancel-if-queue
/ hotword-max-duration
/ hotword-min-duration
/ interpret-text
/ dtmf-buffer-time
/ clear-dtmf-buffer
/ early-no-match
If a recognizer resource supports voice enrolled grammars, the following header fields are also used.
認識リソースが音声登録済みの文法をサポートしている場合は、次のヘッダーフィールドも使用されます。
enrollment-header = num-min-consistent-pronunciations
/ consistency-threshold
/ clash-threshold
/ personal-grammar-uri
/ enroll-utterance
/ phrase-id
/ phrase-nl
/ weight
/ save-best-waveform
/ new-phrase-id
/ confusable-phrases-uri
/ abort-phrase-enrollment
For enrollment-specific header fields that can appear as part of SET-PARAMS or GET-PARAMS methods, the following general rule applies: the START-PHRASE-ENROLLMENT method MUST be invoked before these header fields may be set through the SET-PARAMS method or retrieved through the GET-PARAMS method.
SET-PARAMSまたはGET-PARAMSメソッドの一部として表示できる登録固有のヘッダーフィールドには、次の一般的なルールが適用されます。これらのヘッダーフィールドをSET-PARAMSメソッドで設定する前に、START-PHRASE-ENROLLMENTメソッドを呼び出す必要があります。または、GET-PARAMSメソッドを使用して取得します。
Note that the Waveform-URI header field of the Recognizer resource can also appear in the response to the END-PHRASE-ENROLLMENT method.
RecognizerリソースのWaveform-URIヘッダーフィールドは、END-PHRASE-ENROLLMENTメソッドへの応答にも表示される可能性があることに注意してください。
When a recognizer resource recognizes or matches a spoken phrase with some portion of the grammar, it associates a confidence level with that match. The Confidence-Threshold header field tells the recognizer resource what confidence level the client considers a successful match. This is a float value between 0.0-1.0 indicating the recognizer's confidence in the recognition. If the recognizer determines that there is no candidate match with a confidence that is greater 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 header field is implementation specific, as is the interpretation of any specific value for this header field. Although values for servers from different vendors are not comparable, it is expected that clients will tune this value over time for a given server.
認識リソースが口頭によるフレーズを認識または文法の一部と一致させると、その一致に信頼レベルが関連付けられます。 Confidence-Thresholdヘッダーフィールドは、クライアントが一致と見なした信頼レベルを認識リソースに通知します。これは0.0〜1.0の浮動小数点値で、認識における認識機能の信頼度を示します。認識機能が、信頼しきい値よりも高い信頼と一致する候補がないと判断した場合、認識結果として不一致を返す必要があります。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの特定の値の解釈と同様に、このヘッダーフィールドのデフォルト値は実装固有です。異なるベンダーのサーバーの値は比較可能ではありませんが、クライアントは特定のサーバーに対して時間の経過とともにこの値を調整することが予想されます。
confidence-threshold = "Confidence-Threshold" ":" FLOAT CRLF
Confidence-threshold = "Confidence-Threshold" "：" FLOAT CRLF
To filter out background noise and not mistake it for speech, the recognizer resource supports a variable level of sound sensitivity. The Sensitivity-Level header field is a float value between 0.0 and 1.0 and allows the client to set the sensitivity level for the recognizer. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. A higher value for this header field means higher sensitivity. The default value for this header field is implementation specific, as is the interpretation of any specific value for this header field. Although values for servers from different vendors are not comparable, it is expected that clients will tune this value over time for a given server.
バックグラウンドノイズを取り除き、それを音声と間違えないように、認識リソースはさまざまなレベルの音声感度をサポートしています。 Sensitivity-Levelヘッダーフィールドは0.0〜1.0の浮動小数点値であり、クライアントが認識機能の感度レベルを設定できるようにします。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値が大きいほど、感度が高くなります。このヘッダーフィールドの特定の値の解釈と同様に、このヘッダーフィールドのデフォルト値は実装固有です。異なるベンダーのサーバーの値は比較可能ではありませんが、クライアントは特定のサーバーに対して時間の経過とともにこの値を調整することが予想されます。
sensitivity-level = "Sensitivity-Level" ":" FLOAT CRLF
感度レベル= "感度レベル" "：" FLOAT CRLF
Depending on the implementation and capability of the recognizer resource it may be tunable towards Performance or Accuracy. Higher accuracy may mean more processing and higher CPU utilization, meaning fewer active sessions per server and vice versa. The value is a float between 0.0 and 1.0. A value of 0.0 means fastest recognition. A value of 1.0 means best accuracy. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. The default value for this header field is implementation specific. Although values for servers from different vendors are not comparable, it is expected that clients will tune this value over time for a given server.
レコグナイザリソースの実装と機能によっては、パフォーマンスまたは精度に合わせて調整できる場合があります。精度が高いほど、処理が多くなり、CPU使用率が高くなる可能性があります。つまり、サーバーごとのアクティブセッションが少なくなり、逆もまた同様です。値は0.0〜1.0の浮動小数点です。 0.0の値は最も速い認識を意味します。値1.0は、最高の精度を意味します。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドのデフォルト値は実装固有です。異なるベンダーのサーバーの値は比較可能ではありませんが、クライアントは特定のサーバーに対して時間の経過とともにこの値を調整することが予想されます。
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" FLOAT CRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" "：" FLOAT CRLF
When the recognizer matches an incoming stream with the grammar, it may come up with more than one alternative match because of confidence levels in certain words or conversation paths. If this header field is not specified, by default, the recognizer resource returns only the best match above the confidence threshold. The client, by setting this header field, can ask the recognition resource to send it more than one alternative. All alternatives must still be above the Confidence-Threshold. A value greater than one does not guarantee that the recognizer will provide the requested number of alternatives. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. The minimum value for this header field is 1. The default value for this header field is 1.
認識エンジンが着信ストリームと文法を照合する場合、特定の単語または会話パスの信頼レベルのため、複数の代替照合が行われることがあります。このヘッダーフィールドが指定されていない場合、デフォルトでは、認識機能リソースは信頼しきい値を超えた最良の一致のみを返します。クライアントは、このヘッダーフィールドを設定することにより、認識リソースに複数の代替を送信するように要求できます。すべての代替案は、依然として信頼しきい値を超えている必要があります。 1より大きい値は、認識機能が要求された数の代替を提供することを保証しません。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの最小値は1です。このヘッダーフィールドのデフォルト値は1です。
n-best-list-length = "N-Best-List-Length" ":" 1*19DIGIT CRLF
When the recognizer detects barge-in-able input and generates a START-OF-INPUT event, that event MUST carry this header field to specify whether the input that caused the barge-in was DTMF or speech.
認識機能が割り込み可能入力を検出し、START-OF-INPUTイベントを生成する場合、そのイベントはこのヘッダーフィールドを搬送して、割り込みの原因となった入力がDTMFか音声かを指定する必要があります。
input-type = "Input-Type" ":" inputs CRLF
inputs = "speech" / "dtmf"
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 with a Completion-Cause of "no-input-timeout" and terminate the recognition operation. The client can use the No-Input-Timeout header field to set this timeout. The value is in milliseconds and can range from 0 to an implementation-specific maximum value. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. The default value is implementation specific.
認識が開始され、一定の時間音声が検出されない場合、認識機能は「no-input-timeout」のCompletion-CauseでRECOGNITION-COMPLETEイベントをクライアントに送信し、認識操作を終了できます。クライアントは、No-Input-Timeoutヘッダーフィールドを使用して、このタイムアウトを設定できます。値はミリ秒単位で、0から実装固有の最大値までの範囲にすることができます。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。デフォルト値は実装固有です。
no-input-timeout = "No-Input-Timeout" ":" 1*19DIGIT CRLF
When recognition is started and there is no match for a certain period of time, the recognizer can send a RECOGNITION-COMPLETE event to the client and terminate the recognition operation. The Recognition-Timeout header field allows the client to set this timeout value. The value is in milliseconds. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value is 10 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
認識が開始され、一定期間一致しない場合、レコグナイザはRECOGNITION-COMPLETEイベントをクライアントに送信し、認識操作を終了できます。 Recognition-Timeoutヘッダーフィールドを使用すると、クライアントはこのタイムアウト値を設定できます。値はミリ秒単位です。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。デフォルト値は10秒です。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
recognition-timeout = "Recognition-Timeout" ":" 1*19DIGIT CRLF
If the Save-Waveform header field is set to "true", the recognizer MUST record the incoming audio stream of the recognition into a stored form and provide a URI for the client to access it. This header field MUST be present in the RECOGNITION-COMPLETE event if the Save-Waveform header field was set to "true". The value of the header field MUST be empty if there was some error condition preventing the server from recording. Otherwise, the URI generated by the server MUST be unambiguous across the server and all its recognition sessions. The content associated with the URI MUST be available to the client until the MRCPv2 session terminates.
Save-Waveformヘッダーフィールドが「true」に設定されている場合、レコグナイザは認識の着信オーディオストリームを保存されたフォームに記録し、クライアントがアクセスするためのURIを提供する必要があります。 Save-Waveformヘッダーフィールドが「true」に設定されている場合、このヘッダーフィールドはRECOGNITION-COMPLETEイベントに存在する必要があります。サーバーが記録できないエラー条件が発生した場合、ヘッダーフィールドの値は空でなければなりません。それ以外の場合、サーバーによって生成されたURIは、サーバーとそのすべての認識セッションにわたって明確でなければなりません。 URIに関連付けられたコンテンツは、MRCPv2セッションが終了するまでクライアントで使用できる必要があります。
Similarly, if the Save-Best-Waveform header field is set to "true", the recognizer MUST save the audio stream for the best repetition of the phrase that was used during the enrollment session. The recognizer MUST then record the recognized audio and make it available to the client by returning a URI in the Waveform-URI header field in the response to the END-PHRASE-ENROLLMENT method. The value of the header field MUST be empty if there was some error condition preventing the server from recording. Otherwise, the URI generated by the server MUST be unambiguous across the server and all its recognition sessions. The content associated with the URI MUST be available to the client until the MRCPv2 session terminates. See the discussion on the sensitivity of saved waveforms in Section 12.
同様に、Save-Best-Waveformヘッダーフィールドが「true」に設定されている場合、認識機能は、登録セッション中に使用されたフレーズの最適な繰り返しのためにオーディオストリームを保存する必要があります。次に、認識エンジンは認識された音声を録音し、END-PHRASE-ENROLLMENTメソッドへの応答でWaveform-URIヘッダーフィールドにURIを返すことにより、クライアントが利用できるようにする必要があります。サーバーが記録できないエラー条件が発生した場合、ヘッダーフィールドの値は空でなければなりません。それ以外の場合、サーバーによって生成されたURIは、サーバーとそのすべての認識セッションにわたって明確でなければなりません。 URIに関連付けられたコンテンツは、MRCPv2セッションが終了するまでクライアントで使用できる必要があります。セクション12の保存された波形の感度に関する説明を参照してください。
The server MUST also return the size in octets and the duration in milliseconds of the recorded audio waveform as parameters associated with the header field.
サーバーは、ヘッダーフィールドに関連付けられたパラメーターとして、記録されたオーディオ波形のオクテット単位のサイズとミリ秒単位の期間も返す必要があります。
waveform-uri = "Waveform-URI" ":" ["<" uri ">"
";" "size" "=" 1*19DIGIT
";" "duration" "=" 1*19DIGIT] CRLF
This header field MAY be specified in the SET-PARAMS, GET-PARAMS, or the RECOGNIZE methods and tells the server resource the media type in which to store captured audio or video, such as the one captured and returned by the Waveform-URI header field.
このヘッダーフィールドは、SET-PARAMS、GET-PARAMS、またはRECOGNIZEメソッドで指定される場合があり、Waveform-URIヘッダーによってキャプチャされて返されたものなど、キャプチャされたオーディオまたはビデオを格納するメディアタイプをサーバーリソースに通知しますフィールド。
media-type = "Media-Type" ":" media-type-value CRLF
media-type = "Media-Type" "：" media-type-value CRLF
This optional header field specifies a URI pointing to audio content to be processed by the RECOGNIZE operation. This enables the client to request recognition from a specified buffer or audio file.
このオプションのヘッダーフィールドは、RECOGNIZE操作で処理されるオーディオコンテンツを指すURIを指定します。これにより、クライアントは指定されたバッファまたはオーディオファイルからの認識を要求できます。
input-waveform-uri = "Input-Waveform-URI" ":" uri CRLF
input-waveform-uri = "Input-Waveform-URI" "：" uri CRLF
This header field MUST be part of a RECOGNITION-COMPLETE event coming from the recognizer resource to the client. It 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. In the ABNF below, the cause-code contains a numerical value selected from the Cause-Code column of the following table. The cause-name contains the corresponding token selected from the Cause-Name column.
このヘッダーフィールドは、認識リソースからクライアントに送信されるRECOGNITION-COMPLETEイベントの一部である必要があります。これは、RECOGNIZEメソッドが完了した理由を示しています。このヘッダーフィールドは、DEFINE-GRAMMARおよびRECOGNIZE応答で送信する必要があります（失敗ステータスとCOMPLETE状態で戻る場合）。以下のABNFでは、原因コードには、次の表の「原因コード」列から選択された数値が含まれています。 cause-nameには、Cause-Name列から選択された対応するトークンが含まれます。
completion-cause = "Completion-Cause" ":" cause-code SP
cause-name CRLF
cause-code = 3DIGIT
cause-name = *VCHAR
+------------+-----------------------+------------------------------+
| Cause-Code | Cause-Name | Description |
+------------+-----------------------+------------------------------+
| 000 | success | RECOGNIZE completed with a |
| | | match or DEFINE-GRAMMAR |
| | | succeeded in downloading and |
| | | compiling the grammar. |
| | | |
| 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 | hotword-maxtime | RECOGNIZE in hotword mode |
| | | completed without a match |
| | | due to a |
| | | recognition-timeout. |
| | | |
| 004 | grammar-load-failure | RECOGNIZE failed due to |
| | | grammar load failure. |
| | | |
| 005 | grammar-compilation- | RECOGNIZE failed due to |
| | failure | grammar compilation failure. |
| | | |
| 006 | recognizer-error | RECOGNIZE request terminated |
| | | prematurely due to a |
| | | recognizer error. |
| | | |
| 007 | speech-too-early | RECOGNIZE request terminated |
| | | because speech was too |
| | | early. This happens when the |
| | | audio stream is already |
| | | "in-speech" when the |
| | | RECOGNIZE request was |
| | | received. |
| | | |
| 008 | success-maxtime | RECOGNIZE request terminated |
| | | because speech was too long |
| | | but whatever was spoken till |
| | | that point was a full match. |
| | | |
| 009 | uri-failure | Failure accessing a URI. |
| | | |
| 010 | language-unsupported | Language not supported. |
| | | |
| 011 | cancelled | A new RECOGNIZE cancelled |
| | | this one, or a prior |
| | | RECOGNIZE failed while this |
| | | one was still in the queue. |
| | | |
| 012 | semantics-failure | Recognition succeeded, but |
| | | semantic interpretation of |
| | | the recognized input failed. |
| | | The RECOGNITION-COMPLETE |
| | | event MUST contain the |
| | | Recognition result with only |
| | | input text and no |
| | | interpretation. |
| | | |
| 013 | partial-match | Speech Incomplete Timeout |
| | | expired before there was a |
| | | full match. But whatever was |
| | | spoken till that point was a |
| | | partial match to one or more |
| | | grammars. |
| | | |
| 014 | partial-match-maxtime | The Recognition-Timeout |
| | | expired before full match |
| | | was achieved. But whatever |
| | | was spoken till that point |
| | | was a partial match to one |
| | | or more grammars. |
| | | |
| 015 | no-match-maxtime | The Recognition-Timeout |
| | | expired. Whatever was spoken |
| | | till that point did not |
| | | match any of the grammars. |
| | | This cause could also be |
| | | returned if the recognizer |
| | | does not support detecting |
| | | partial grammar matches. |
| | | |
| 016 | grammar-definition- | Any DEFINE-GRAMMAR error |
| | failure | other than |
| | | grammar-load-failure and |
| | | grammar-compilation-failure. |
+------------+-----------------------+------------------------------+
This header field MAY be specified in a RECOGNITION-COMPLETE event coming from the recognizer resource to the client. This contains the reason text behind the RECOGNIZE request completion. The server uses this header field to communicate text describing the reason for the failure, such as the specific error encountered in parsing a grammar markup.
このヘッダーフィールドは、認識リソースからクライアントに送られるRECOGNITION-COMPLETEイベントで指定される場合があります。これには、RECOGNIZE要求の完了の背後にある理由テキストが含まれます。サーバーはこのヘッダーフィールドを使用して、文法マークアップの解析中に発生した特定のエラーなど、失敗の理由を説明するテキストを伝えます。
The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients MUST NOT interpret the completion reason text.
完了理由のテキストは、クライアントがログで使用するため、およびデバッグと計測の目的で提供されます。クライアントは完了理由テキストを解釈してはなりません。
completion-reason = "Completion-Reason" ":" quoted-string CRLF
completion-reason = "Completion-Reason" "："引用文字列CRLF
This header field 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 typed media message body. If the server returns a recognizer context block, the response MUST contain this header field and its value MUST match the Content-ID of the corresponding media block.
このヘッダーフィールドは、SET-PARAMSまたはGET-PARAMSリクエストの一部として送信される場合があります。 GET-PARAMSメソッドに値のないこのヘッダーフィールドが含まれている場合、それは認識機能への要求であり、認識機能コンテキストブロックを返します。そのようなメッセージへの応答は、型付けされたメディアメッセージ本文として認識コンテキストブロックを含むかもしれません。サーバーがレコグナイザコンテキストブロックを返す場合、応答にはこのヘッダーフィールドが含まれている必要があり、その値は対応するメディアブロックのContent-IDと一致する必要があります。
If the SET-PARAMS method contains this header field, it MUST also contain a message body containing the recognizer context data and a Content-ID matching this header field value. This Content-ID MUST match the Content-ID that came with the context data during the GET-PARAMS operation.
SET-PARAMSメソッドにこのヘッダーフィールドが含まれている場合は、レコグナイザコンテキストデータを含むメッセージ本文と、このヘッダーフィールド値に一致するContent-IDも含まれている必要があります。このContent-IDは、GET-PARAMS操作中にコンテキストデータに付属するContent-IDと一致する必要があります。
An implementation choosing to use this mechanism to hand off recognizer context data between servers MUST distinguish its implementation-specific block of data by using an IANA-registered content type in the IANA Media Type vendor tree.
このメカニズムを使用してサーバー間で認識機能コンテキストデータを渡すことを選択する実装は、IANA Media TypeベンダーツリーのIANA登録コンテンツタイプを使用して、実装固有のデータブロックを区別する必要があります。
recognizer-context-block = "Recognizer-Context-Block" ":" [1*VCHAR] CRLF
cognizer-context-block = "Recognizer-Context-Block" "：" [1 * VCHAR] CRLF
This header field 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 MUST NOT start the timers until the client sends a START-INPUT-TIMERS request to the recognizer. This is useful in the scenario when the recognizer and synthesizer engines are not part of the same session. In such configurations, when a kill-on-barge-in prompt is being played (see Section 8.4.2), the client wants the RECOGNIZE request to be simultaneously active so that it can detect and implement kill-on-barge-in. However, the recognizer SHOULD NOT start the no-input timers until the prompt is finished. The default value is "true".
このヘッダーフィールドは、認識リクエストの一部として送信される場合があります。 falseの値は、認識機能に認識を開始するよう指示しますが、まだ入力なしタイマーを開始しないよう指示します。認識エンジンは、クライアントがSTART-INPUT-TIMERS要求を認識エンジンに送信するまでタイマーを開始してはなりません（MUST NOT）。これは、認識エンジンとシンセサイザエンジンが同じセッションの一部ではないシナリオで役立ちます。このような構成では、kill-on-barge-inプロンプトが再生されているとき（セクション8.4.2を参照）、クライアントはkill-on-barge-inを検出して実装できるように、RECOGNIZE要求を同時にアクティブにすることを望みます。ただし、認識機能は、プロンプトが終了するまで無入力タイマーを開始しないでください。デフォルト値は「true」です。
start-input-timers = "Start-Input-Timers" ":" BOOLEAN CRLF
start-input-timers = "Start-Input-Timers" "：" BOOLEAN CRLF
This header field specifies the length of silence required following user speech before the speech recognizer finalizes a result (either accepting it or generating a no-match result). The Speech-Complete-Timeout value applies when the recognizer currently has a complete match against an active grammar, and specifies how long the recognizer MUST wait for more input before declaring a match. By contrast, the Speech-Incomplete-Timeout is used when the speech is an incomplete match to an active grammar. The value is in milliseconds.
このヘッダーフィールドは、音声認識機能が結果を確定する（受け入れるか一致しない結果を生成する）前に、ユーザーの音声に続いて必要な無音の長さを指定します。 Speech-Complete-Timeout値は、認識機能が現在アクティブな文法に対して完全に一致している場合に適用され、認識機能が一致を宣言する前にさらに入力を待機する必要がある時間を指定します。対照的に、Speech-Incomplete-Timeoutは、音声がアクティブな文法と不完全に一致する場合に使用されます。値はミリ秒単位です。
speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*19DIGIT CRLF
A long Speech-Complete-Timeout value delays the result to the client and therefore makes the application's response to a user slow. A short Speech-Complete-Timeout may lead to an utterance being broken up inappropriately. Reasonable speech complete timeout values are typically in the range of 0.3 seconds to 1.0 seconds. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value for this header field is implementation specific. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
Speech-Complete-Timeout値が長いと、クライアントへの結果が遅延するため、ユーザーへのアプリケーションの応答が遅くなります。 Speech-Complete-Timeoutが短いと、発話が不適切に分割される可能性があります。合理的なスピーチ完了タイムアウト値は、通常0.3秒から1.0秒の範囲です。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。このヘッダーフィールドのデフォルト値は実装固有です。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
This header field specifies the required length of silence following user speech after which a recognizer finalizes a result. The incomplete timeout applies when the speech prior to the silence is an incomplete match of all active grammars. In this case, once the timeout is triggered, the partial result is rejected (with a Completion-Cause of "partial-match"). The value is in milliseconds. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value for this header field is implementation specific.
このヘッダーフィールドは、認識機能が結果を確定するまでの、ユーザーの音声に続く必要な無音の長さを指定します。不完全なタイムアウトは、無音の前の音声がすべてのアクティブな文法の不完全な一致である場合に適用されます。この場合、タイムアウトがトリガーされると、部分結果は拒否されます（「部分一致」のCompletion-Cause）。値はミリ秒単位です。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。このヘッダーフィールドのデフォルト値は実装固有です。
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*19DIGIT CRLF
speech-incomplete-timeout = "Speech-Incomplete-Timeout" "：" 1 * 19DIGIT 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 Speech-Complete-Timeout is used when the speech is a complete match to an active grammar and no further spoken words can continue to represent a match.
Speech-Incomplete-Timeoutは、無音前の発話がアクティブな文法の完全一致である場合にも適用されますが、さらに話すことはできますが、文法にはまだ一致します。対照的に、Speech-Complete-Timeoutは、スピーチがアクティブな文法と完全に一致し、それ以上の話し言葉が一致を表すことができない場合に使用されます。
A long Speech-Incomplete-Timeout value delays the result to the client and therefore makes the application's response to a user slow. A short Speech-Incomplete-Timeout may lead to an utterance being broken up inappropriately.
Speech-Incomplete-Timeout値が長いと、クライアントへの結果が遅延するため、ユーザーへのアプリケーションの応答が遅くなります。 Speech-Incomplete-Timeoutが短いと、発話が不適切に分割される可能性があります。
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.
Speech-Incomplete-Timeoutは、通常、Speech-Complete-Timeoutよりも長く、ユーザーが発話の途中で一時停止する（たとえば、呼吸する）ことができます。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
This header field specifies the inter-digit timeout value to use when recognizing DTMF input. The value is in milliseconds. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value is 5 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドは、DTMF入力を認識するときに使用する桁間タイムアウト値を指定します。値はミリ秒単位です。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。デフォルト値は5秒です。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*19DIGIT CRLF
This header field specifies the terminating timeout to use when recognizing DTMF input. The DTMF-Term-Timeout applies only when no additional input is allowed by the grammar; otherwise, the DTMF-Interdigit-Timeout applies. The value is in milliseconds. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value is 10 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドは、DTMF入力を認識するときに使用する終了タイムアウトを指定します。 DTMF-Term-Timeoutは、文法で追加の入力が許可されていない場合にのみ適用されます。それ以外の場合は、DTMF-Interdigit-Timeoutが適用されます。値はミリ秒単位です。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。デフォルト値は10秒です。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*19DIGIT CRLF
This header field specifies the terminating DTMF character for DTMF input recognition. The default value is NULL, which is indicated by an empty header field value. 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" ":" VCHAR CRLF
dtmf-term-char = "DTMF-Term-Char" "：" VCHAR CRLF
When a recognizer needs to fetch or access a URI and the access fails, the server SHOULD provide the failed URI in this header field in the method response, unless there are multiple URI failures, in which case one of the failed URIs MUST be provided in this header field in the method response.
認識エンジンがURIをフェッチまたはアクセスする必要があり、アクセスが失敗した場合、サーバーは、複数のURIエラーがない限り、失敗したURIをメソッドレスポンスのこのヘッダーフィールドに提供する必要があります。その場合、失敗したURIの1つを提供する必要があります。メソッドレスポンスのこのヘッダーフィールド。
failed-uri = "Failed-URI" ":" absoluteURI CRLF
failed-uri = "Failed-URI" "：" absoluteURI CRLF
When a recognizer method needs a recognizer to fetch or access a URI and the access fails, the server MUST provide the URI-specific or protocol-specific response code for the URI in the Failed-URI header field through this header field in the method response. The value encoding is UTF-8 (RFC 3629 [RFC3629]) to accommodate any access protocol, some of which might have a response string instead of a numeric response code.
認識機能メソッドがURIをフェッチまたはアクセスするために認識機能を必要とし、アクセスが失敗した場合、サーバーは、メソッド応答のこのヘッダーフィールドを介して、Failed-URIヘッダーフィールドにURIのURI固有またはプロトコル固有の応答コードを提供する必要があります。 。値のエンコードはUTF-8（RFC 3629 [RFC3629]）で、あらゆるアクセスプロトコルに対応します。その一部には、数値応答コードの代わりに応答文字列が含まれる場合があります。
failed-uri-cause = "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
This header field allows the client to request the recognizer resource to save the audio input to the recognizer. The recognizer resource MUST then attempt to record the recognized audio, without endpointing, 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 content is otherwise not available, the recognizer MUST return an empty Waveform-URI header field. The default value for this field is "false". This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. See the discussion on the sensitivity of saved waveforms in Section 12.
このヘッダーフィールドを使用すると、クライアントは認識機能リソースに音声入力を認識機能に保存するように要求できます。次に、認識リソースは、認識された音声をエンドポイントなしで録音し、RECOGNITION-COMPLETEイベントのWaveform-URIヘッダーフィールドに返されたURIの形式でクライアントが利用できるようにする必要があります。ストリームの記録中にエラーが発生した場合、またはオーディオコンテンツが利用できない場合、認識機能は空のWaveform-URIヘッダーフィールドを返さなければなりません（MUST）。このフィールドのデフォルト値は「false」です。このヘッダーフィールドは、RECOGNIZE、SET-PARAMS、またはGET-PARAMSで発生する場合があります。セクション12の保存された波形の感度に関する説明を参照してください。
save-waveform = "Save-Waveform" ":" BOOLEAN CRLF
save-waveform = "Save-Waveform" "：" BOOLEAN CRLF
This header field MAY be specified in a RECOGNIZE request and allows the client to tell the server that, from this point on, further input audio comes from a different audio source, channel, or speaker. If the recognizer resource had collected any input statistics or adaptation state, the recognizer resource MUST do what is appropriate for the specific recognition technology, which includes but is not limited to discarding any collected input statistics or adaptation state before starting the RECOGNIZE request. Note that if there are multiple resources that are sharing a media stream and are collecting or using this data, and the client issues this header field to one of the resources, the reset operation applies to all resources that use the shared media stream. This helps in a number of use cases, including where the client wishes to reuse an open recognition session with an existing media session for multiple telephone calls.
このヘッダーフィールドはRECOGNIZEリクエストで指定される場合があり、これにより、クライアントはサーバーに、これ以降、別のオーディオソース、チャネル、またはスピーカーからの入力オーディオであることを通知できます。レコグナイザリソースが入力統計または適応状態を収集した場合、レコグナイザリソースは、特定の認識テクノロジに適したものを実行する必要があります。これには、RECOGNIZE要求を開始する前に、収集された入力統計または適応状態を破棄することが含まれますが、これに限定されません。メディアストリームを共有し、このデータを収集または使用しているリソースが複数あり、クライアントがこのヘッダーフィールドをリソースの1つに発行した場合、リセット操作は共有メディアストリームを使用するすべてのリソースに適用されます。これは、クライアントが複数の通話のために既存のメディアセッションでオープン認識セッションを再利用したい場合など、多くの使用例で役立ちます。
new-audio-channel = "New-Audio-Channel" ":" BOOLEAN CRLF
new-audio-channel = "New-Audio-Channel" "："ブールCRLF
This header field specifies the language of recognition grammar data within a session or request, if it is not specified within the data. The value of this header field MUST follow RFC 5646 [RFC5646] for its values. This MAY occur in DEFINE-GRAMMAR, RECOGNIZE, SET-PARAMS, or GET-PARAMS requests.
このヘッダーフィールドは、セッション内またはリクエスト内の認識文法データの言語を指定します（データ内で指定されていない場合）。このヘッダーフィールドの値は、その値についてRFC 5646 [RFC5646]に従う必要があります。これは、DEFINE-GRAMMAR、RECOGNIZE、SET-PARAMS、またはGET-PARAMSリクエストで発生する場合があります。
speech-language = "Speech-Language" ":" 1*VCHAR CRLF
This header field lets the client request the server to buffer the utterance associated with this recognition request into a buffer available to a co-resident verifier resource. The buffer is shared across resources within a session and is allocated when a verifier resource is added to this session. The client MUST NOT send this header field unless a verifier resource is instantiated for the session. The buffer is released when the verifier resource is released from the session.
このヘッダーフィールドを使用すると、クライアントはサーバーに、この認識要求に関連付けられている発話を、共存する検証リソースが利用できるバッファーにバッファーするように要求できます。バッファはセッション内のリソース間で共有され、ベリファイアリソースがこのセッションに追加されるときに割り当てられます。セッションに対してベリファイアリソースがインスタンス化されない限り、クライアントはこのヘッダーフィールドを送信してはなりません（MUST NOT）。ベリファイアリソースがセッションから解放されると、バッファが解放されます。
This header field specifies what mode the RECOGNIZE method will operate in. The value choices are "normal" or "hotword". If the value is "normal", the RECOGNIZE starts matching speech and DTMF to the grammars specified in the RECOGNIZE request. If any portion of the speech does not match the grammar, the RECOGNIZE command completes with a no-match status. Timers may be active to detect speech in the audio (see Section 9.4.14), so the RECOGNIZE method may complete because of a timeout waiting for speech. If the value of this header field is "hotword", the RECOGNIZE method operates in hotword mode, where it only looks for the particular keywords or DTMF sequences specified in the grammar and ignores silence or other speech in the audio stream. The default value for this header field is "normal". This header field MAY occur on the RECOGNIZE method.
このヘッダーフィールドは、RECOGNIZEメソッドが動作するモードを指定します。値の選択肢は、「通常」または「ホットワード」です。値が "normal"の場合、RECOGNIZEは音声とDTMFをRECOGNIZE要求で指定された文法と照合し始めます。スピーチのいずれかの部分が文法と一致しない場合、RECOGNIZEコマンドは一致しないステータスで完了します。タイマーがアクティブになって音声のスピーチを検出する場合があり（セクション9.4.14を参照）、スピーチを待つタイムアウトのためにRECOGNIZEメソッドが完了する場合があります。このヘッダーフィールドの値が「ホットワード」の場合、RECOGNIZEメソッドはホットワードモードで動作し、文法で指定された特定のキーワードまたはDTMFシーケンスのみを検索し、オーディオストリーム内の無音またはその他の音声を無視します。このヘッダーフィールドのデフォルト値は「通常」です。このヘッダーフィールドは、RECOGNIZEメソッドで発生する場合があります。
recognition-mode = "Recognition-Mode" ":"
"normal" / "hotword" CRLF
This header field specifies what will happen if the client attempts to invoke another RECOGNIZE method when this RECOGNIZE request is already in progress for the resource. The value for this header field is a Boolean. A value of "true" means the server MUST terminate this RECOGNIZE request, with a Completion-Cause of "cancelled", if the client issues another RECOGNIZE request for the same resource. A value of "false" for this header field indicates to the server that this RECOGNIZE request will continue to completion, and if the client issues more RECOGNIZE requests to the same resource, they are queued. When the currently active RECOGNIZE request is stopped or completes with a successful match, the first RECOGNIZE method in the queue becomes active. If the current RECOGNIZE fails, all RECOGNIZE methods in the pending queue are cancelled, and each generates a RECOGNITION-COMPLETE event with a Completion-Cause of "cancelled". This header field MUST be present in every RECOGNIZE request. There is no default value.
このヘッダーフィールドは、このRECOGNIZEリクエストがリソースに対してすでに進行中のときに、クライアントが別のRECOGNIZEメソッドを呼び出そうとした場合にどうなるかを指定します。このヘッダーフィールドの値はブール値です。 「true」の値は、クライアントが同じリソースに対して別のRECOGNIZE要求を発行した場合、サーバーがこのRECOGNIZE要求を「キャンセル」のCompletion-Causeで終了しなければならないことを意味します。このヘッダーフィールドの値が "false"の場合、このRECOGNIZE要求は引き続き完了し、クライアントが同じリソースに対してさらにRECOGNIZE要求を発行すると、それらはキューに入れられます。現在アクティブなRECOGNIZE要求が停止するか、一致が成功して完了すると、キュー内の最初のRECOGNIZEメソッドがアクティブになります。現在のRECOGNIZEが失敗した場合、保留中のキュー内のすべてのRECOGNIZEメソッドがキャンセルされ、それぞれがCompletion-Causeが "cancelled"のRECOGNITION-COMPLETEイベントを生成します。このヘッダーフィールドは、すべてのRECOGNIZEリクエストに存在する必要があります。デフォルト値はありません。
cancel-if-queue = "Cancel-If-Queue" ":" BOOLEAN CRLF
cancel-if-queue = "Cancel-If-Queue" "："ブールCRLF
This header field MAY be sent in a hotword mode RECOGNIZE request. It specifies the maximum length of an utterance (in seconds) that will be considered for hotword recognition. This header field, along with Hotword-Min-Duration, can be used to tune performance by preventing the recognizer from evaluating utterances that are too short or too long to be one of the hotwords in the grammar(s). The value is in milliseconds. The default is implementation dependent. If present in a RECOGNIZE request specifying a mode other than "hotword", the header field is ignored.
このヘッダーフィールドは、ホットワードモードのRECOGNIZEリクエストで送信される場合があります。ホットワード認識で考慮される発話の最大長（秒単位）を指定します。このヘッダーフィールドは、Hotword-Min-Durationと一緒に使用して、認識機能が短すぎたり長すぎて文法のホットワードの1つにならないようにして、パフォーマンスを調整できます。値はミリ秒単位です。デフォルトは実装に依存します。 「ホットワード」以外のモードを指定するRECOGNIZE要求に存在する場合、ヘッダーフィールドは無視されます。
hotword-max-duration = "Hotword-Max-Duration" ":" 1*19DIGIT CRLF
hotword-max-duration = "Hotword-Max-Duration" "：" 1 * 19DIGIT CRLF
This header field MAY be sent in a hotword mode RECOGNIZE request. It specifies the minimum length of an utterance (in seconds) that will be considered for hotword recognition. This header field, along with Hotword-Max-Duration, can be used to tune performance by preventing the recognizer from evaluating utterances that are too short or too long to be one of the hotwords in the grammar(s). The value is in milliseconds. The default value is implementation dependent. If present in a RECOGNIZE request specifying a mode other than "hotword", the header field is ignored.
このヘッダーフィールドは、ホットワードモードのRECOGNIZEリクエストで送信される場合があります。これは、ホットワード認識で考慮される発話の最小の長さ（秒単位）を指定します。このヘッダーフィールドは、Hotword-Max-Durationと一緒に使用して、認識機能が短すぎたり長すぎて文法のホットワードの1つにならないようにして、パフォーマンスを調整することができます。値はミリ秒単位です。デフォルト値は実装に依存します。 「ホットワード」以外のモードを指定するRECOGNIZE要求に存在する場合、ヘッダーフィールドは無視されます。
hotword-min-duration = "Hotword-Min-Duration" ":" 1*19DIGIT CRLF
The value of this header field is used to provide a pointer to the text for which a natural language interpretation is desired. The value is either a URI or text. If the value is a URI, it MUST be a Content-ID that refers to an entity of type 'text/plain' in the body of the message. Otherwise, the server MUST treat the value as the text to be interpreted. This header field MUST be used when invoking the INTERPRET method.
このヘッダーフィールドの値は、自然言語解釈が必要なテキストへのポインターを提供するために使用されます。値はURIまたはテキストです。値がURIの場合は、メッセージの本文で「text / plain」タイプのエンティティを参照するContent-IDである必要があります。それ以外の場合、サーバーは値を解釈されるテキストとして処理する必要があります。このヘッダーフィールドは、INTERPRETメソッドを呼び出すときに使用する必要があります。
interpret-text = "Interpret-Text" ":" 1*VCHAR CRLF
This header field MAY be specified in a GET-PARAMS or SET-PARAMS method and is used to specify the amount of time, in milliseconds, of the type-ahead buffer for the recognizer. This is the buffer that collects DTMF digits as they are pressed even when there is no RECOGNIZE command active. When a subsequent RECOGNIZE method is received, it MUST look to this buffer to match the RECOGNIZE request. If the digits in the buffer are not sufficient, then it can continue to listen to more digits to match the grammar. The default size of this DTMF buffer is platform specific.
このヘッダーフィールドは、GET-PARAMSまたはSET-PARAMSメソッドで指定される場合があり、認識機能の先行入力バッファーの時間をミリ秒単位で指定するために使用されます。これは、アクティブなRECOGNIZEコマンドがない場合でも、押されたDTMFディジットを収集するバッファです。後続のRECOGNIZEメソッドが受信されると、RECOGNIZEリクエストと一致するようにこのバッファを探す必要があります。バッファ内の数字が十分でない場合、文法に一致するようにさらに数字を聞き取り続けることができます。このDTMFバッファのデフォルトサイズはプラットフォーム固有です。
dtmf-buffer-time = "DTMF-Buffer-Time" ":" 1*19DIGIT CRLF
This header field MAY be specified in a RECOGNIZE method and is used to tell the recognizer to clear the DTMF type-ahead buffer before starting the RECOGNIZE. The default value of this header field is "false", which does not clear the type-ahead buffer before starting the RECOGNIZE method. If this header field is specified to be "true", then the RECOGNIZE will clear the DTMF buffer before starting recognition. This means digits pressed by the caller before the RECOGNIZE command was issued are discarded.
このヘッダーフィールドはRECOGNIZEメソッドで指定することができ（MAY）、RECOGNIZEを開始する前にDTMFタイプアヘッドバッファーをクリアするように認識機能に指示するために使用されます。このヘッダーフィールドのデフォルト値は「false」で、RECOGNIZEメソッドを開始する前に先行入力バッファーをクリアしません。このヘッダーフィールドが「true」に指定されている場合、RECOGNIZEは認識を開始する前にDTMFバッファーをクリアします。つまり、RECOGNIZEコマンドが発行される前に発信者が押した数字は破棄されます。
clear-dtmf-buffer = "Clear-DTMF-Buffer" ":" BOOLEAN CRLF
clear-dtmf-buffer = "Clear-DTMF-Buffer" "：" BOOLEAN CRLF
This header field MAY be specified in a RECOGNIZE method and is used to tell the recognizer that it MUST NOT wait for the end of speech before processing the collected speech to match active grammars. A value of "true" indicates the recognizer MUST do early matching. The default value for this header field if not specified is "false". If the recognizer does not support the processing of the collected audio before the end of speech, this header field can be safely ignored.
このヘッダーフィールドはRECOGNIZEメソッドで指定される場合があり、アクティブな文法と一致するように収集された音声を処理する前に音声認識の終了を待機してはならないことを認識機能に伝えるために使用されます。 「true」の値は、認識エンジンが早期マッチングを実行する必要があることを示します。指定されていない場合、このヘッダーフィールドのデフォルト値は「false」です。認識機能が音声の終了前に収集されたオーディオの処理をサポートしていない場合、このヘッダーフィールドは無視しても問題ありません。
early-no-match = "Early-No-Match" ":" BOOLEAN CRLF
early-no-match = "Early-No-Match" "：" BOOLEAN CRLF
This header field MAY be specified in a START-PHRASE-ENROLLMENT, SET-PARAMS, or GET-PARAMS method and is used to specify the minimum number of consistent pronunciations that must be obtained to voice enroll a new phrase. The minimum value is 1. The default value is implementation specific and MAY be greater than 1.
このヘッダーフィールドは、START-PHRASE-ENROLLMENT、SET-PARAMS、またはGET-PARAMSメソッドで指定される場合があり、新しいフレーズを音声登録するために取得する必要がある一貫した発音の最小数を指定するために使用されます。最小値は1です。デフォルト値は実装固有であり、1より大きい場合があります。
num-min-consistent-pronunciations = "Num-Min-Consistent-Pronunciations" ":" 1*19DIGIT CRLF
num-min-consistent-pronunciations = "Num-Min-Consistent-Pronunciations" "：" 1 * 19DIGIT CRLF
This header field MAY be sent as part of the START-PHRASE-ENROLLMENT, SET-PARAMS, or GET-PARAMS method. Used during voice enrollment, this header field specifies how similar to a previously enrolled pronunciation of the same phrase an utterance needs to be in order to be considered "consistent". The higher the threshold, the closer the match between an utterance and previous pronunciations must be for the pronunciation to be considered consistent. The range for this threshold is a float value between 0.0 and 1.0. The default value for this header field is implementation specific.
このヘッダーフィールドは、START-PHRASE-ENROLLMENT、SET-PARAMS、またはGET-PARAMSメソッドの一部として送信される場合があります。音声登録時に使用されるこのヘッダーフィールドは、同じフレーズの以前に登録された発音と、「一貫性がある」と見なされるために発話が必要な程度を指定します。しきい値が高いほど、発音が一貫していると見なされるためには、発話と以前の発音の一致がより近くなる必要があります。このしきい値の範囲は、0.0〜1.0の浮動小数点値です。このヘッダーフィールドのデフォルト値は実装固有です。
consistency-threshold = "Consistency-Threshold" ":" FLOAT CRLF
整合性のしきい値= "整合性のしきい値" "：" FLOAT CRLF
This header field MAY be sent as part of the START-PHRASE-ENROLLMENT, SET-PARAMS, or GET-PARAMS method. Used during voice enrollment, this header field specifies how similar the pronunciations of two different phrases can be before they are considered to be clashing. For example, pronunciations of phrases such as "John Smith" and "Jon Smits" may be so similar that they are difficult to distinguish correctly. A smaller threshold reduces the number of clashes detected. The range for this threshold is a float value between 0.0 and 1.0. The default value for this header field is implementation specific. Clash testing can be turned off completely by setting the Clash-Threshold header field value to 0.
このヘッダーフィールドは、START-PHRASE-ENROLLMENT、SET-PARAMS、またはGET-PARAMSメソッドの一部として送信される場合があります。音声登録中に使用されるこのヘッダーフィールドは、2つの異なるフレーズの発音が、それらが衝突していると見なされる前にどの程度類似しているかを指定します。たとえば、「John Smith」や「Jon Smits」などのフレーズの発音は非常に似ているため、正しく区別することが難しい場合があります。しきい値を小さくすると、検出されるクラッシュの数が減ります。このしきい値の範囲は、0.0〜1.0の浮動小数点値です。このヘッダーフィールドのデフォルト値は実装固有です。 Clash-Thresholdヘッダーフィールドの値を0に設定すると、クラッシュテストを完全にオフにすることができます。
clash-threshold = "Clash-Threshold" ":" FLOAT CRLF
clash-threshold = "Clash-Threshold" "：" FLOAT CRLF
This header field specifies the speaker-trained grammar to be used or referenced during enrollment operations. Phrases are added to this grammar during enrollment. For example, a contact list for user "Jeff" could be stored at the Personal-Grammar-URI "http://myserver.example.com/myenrollmentdb/jeff-list". The generated grammar syntax MAY be implementation specific. There is no default value for this header field. This header field MAY be sent as part of the START-PHRASE-ENROLLMENT, SET-PARAMS, or GET-PARAMS method.
このヘッダーフィールドは、登録操作中に使用または参照される話者トレーニング済みの文法を指定します。登録時にこの文法にフレーズが追加されます。たとえば、ユーザー「Jeff」の連絡先リストは、Personal-Grammar-URI「http://myserver.example.com/myenrollmentdb/jeff-list」に保存できます。生成された文法構文は実装固有である場合があります。このヘッダーフィールドのデフォルト値はありません。このヘッダーフィールドは、START-PHRASE-ENROLLMENT、SET-PARAMS、またはGET-PARAMSメソッドの一部として送信される場合があります。
personal-grammar-uri = "Personal-Grammar-URI" ":" uri CRLF
personal-grammar-uri = "Personal-Grammar-URI" "：" uri CRLF
This header field MAY be specified in the RECOGNIZE method. If this header field is set to "true" and an Enrollment is active, the RECOGNIZE command MUST add the collected utterance to the personal grammar that is being enrolled. The way in which this occurs is engine specific and may be an area of future standardization. The default value for this header field is "false".
このヘッダーフィールドは、RECOGNIZEメソッドで指定される場合があります。このヘッダーフィールドが "true"に設定され、登録がアクティブな場合、RECOGNIZEコマンドは、登録されている個人の文法に収集された発話を追加する必要があります。これが発生する方法はエンジン固有であり、将来の標準化の領域になる可能性があります。このヘッダーフィールドのデフォルト値は「false」です。
enroll-utterance = "Enroll-Utterance" ":" BOOLEAN CRLF
enroll-utterance = "Enroll-Utterance" "：" BOOLEAN CRLF
This header field in a request identifies a phrase in an existing personal grammar for which enrollment is desired. It is also returned to the client in the RECOGNIZE complete event. This header field MAY occur in START-PHRASE-ENROLLMENT, MODIFY-PHRASE, or DELETE-PHRASE requests. There is no default value for this header field.
リクエストのこのヘッダーフィールドは、登録が必要な既存の個人用文法のフレーズを識別します。また、RECOGNIZE完了イベントでクライアントに返されます。このヘッダーフィールドは、START-PHRASE-ENROLLMENT、MODIFY-PHRASE、またはDELETE-PHRASEリクエストで発生する場合があります。このヘッダーフィールドのデフォルト値はありません。
phrase-id = "Phrase-ID" ":" 1*VCHAR CRLF
This string specifies the interpreted text to be returned when the phrase is recognized. This header field MAY occur in START-PHRASE-ENROLLMENT and MODIFY-PHRASE requests. There is no default value for this header field.
この文字列は、フレーズが認識されたときに返される解釈されたテキストを指定します。このヘッダーフィールドは、START-PHRASE-ENROLLMENTおよびMODIFY-PHRASEリクエストで発生する場合があります。このヘッダーフィールドのデフォルト値はありません。
phrase-nl = "Phrase-NL" ":" 1*UTFCHAR CRLF
The value of this header field represents the occurrence likelihood of a phrase in an enrolled grammar. When using grammar enrollment, the system is essentially constructing a grammar segment consisting of a list of possible match phrases. This can be thought of to be similar to the dynamic construction of a <one-of> tag in the W3C grammar specification. Each enrolled-phrase becomes an item in the list that can be matched against spoken input similar to the <item> within a <one-of> list. This header field allows you to assign a weight to the phrase (i.e., <item> entry) in the <one-of> list that is enrolled. Grammar weights are normalized to a sum of one at grammar compilation time, so a weight value of 1 for each phrase in an enrolled grammar list indicates all items in that list have the same weight. This header field MAY occur in START-PHRASE-ENROLLMENT and MODIFY-PHRASE requests. The default value for this header field is implementation specific.
このヘッダーフィールドの値は、登録された文法での句の出現可能性を表します。文法登録を使用する場合、システムは基本的に、可能な一致句のリストで構成される文法セグメントを構築します。これは、W3C文法仕様での<one-of>タグの動的な構築に似ていると考えることができます。各登録フレーズは、<one-of>リスト内の<item>と同様の音声入力と照合できるリスト内のアイテムになります。このヘッダーフィールドを使用すると、登録されている<one-of>リストのフレーズ（つまり、<item>エントリ）に重みを割り当てることができます。文法の重みは、文法のコンパイル時に1の合計に正規化されるため、登録済みの文法リストの各フレーズの重み値1は、そのリストのすべての項目が同じ重みであることを示します。このヘッダーフィールドは、START-PHRASE-ENROLLMENTおよびMODIFY-PHRASEリクエストで発生する場合があります。このヘッダーフィールドのデフォルト値は実装固有です。
weight = "Weight" ":" FLOAT CRLF
重量= "重量" "：" FLOAT CRLF
This header field allows the client to request the recognizer resource to save the audio stream for the best repetition of the phrase that was used during the enrollment session. The recognizer MUST attempt to 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 response to the END-PHRASE-ENROLLMENT method. If there was an error in recording the stream or the audio data is otherwise not available, the recognizer MUST return an empty Waveform-URI header field. This header field MAY occur in the START-PHRASE-ENROLLMENT, SET-PARAMS, and GET-PARAMS methods.
このヘッダーフィールドを使用すると、クライアントは、認識リソースに、登録セッション中に使用されたフレーズの最適な繰り返しのためにオーディオストリームを保存するように要求できます。認識機能は、認識された音声を録音し、END-PHRASE-ENROLLMENTメソッドへの応答でWaveform-URIヘッダーフィールドに返されたURIの形式でクライアントが利用できるようにする必要があります。ストリームの記録中にエラーが発生した場合、またはオーディオデータがそれ以外の場合に利用できない場合、認識機能は空のWaveform-URIヘッダーフィールドを返さなければなりません（MUST）。このヘッダーフィールドは、START-PHRASE-ENROLLMENT、SET-PARAMS、およびGET-PARAMSメソッドで発生する場合があります。
save-best-waveform = "Save-Best-Waveform" ":" BOOLEAN CRLF
save-best-waveform = "Save-Best-Waveform" "："ブールCRLF
This header field replaces the ID used to identify the phrase in a personal grammar. The recognizer returns the new ID when using an enrollment grammar. This header field MAY occur in MODIFY-PHRASE requests.
このヘッダーフィールドは、個人の文法でフレーズを識別するために使用されるIDを置き換えます。登録文法を使用すると、認識エンジンは新しいIDを返します。このヘッダーフィールドは、MODIFY-PHRASEリクエストで発生する場合があります。
new-phrase-id = "New-Phrase-ID" ":" 1*VCHAR CRLF
This header field specifies a grammar that defines invalid phrases for enrollment. For example, typical applications do not allow an enrolled phrase that is also a command word. This header field MAY occur in RECOGNIZE requests that are part of an enrollment session.
このヘッダーフィールドは、登録に無効なフレーズを定義する文法を指定します。たとえば、一般的なアプリケーションでは、コマンドワードでもある登録済みフレーズは許可されません。このヘッダーフィールドは、登録セッションの一部であるRECOGNIZEリクエストで発生する場合があります。
confusable-phrases-uri = "Confusable-Phrases-URI" ":" uri CRLF
confusable-phrases-uri = "Confusable-Phrases-URI" "：" uri CRLF
This header field MAY be specified in the END-PHRASE-ENROLLMENT method to abort the phrase enrollment, rather than committing the phrase to the personal grammar.
このヘッダーフィールドをEND-PHRASE-ENROLLMENTメソッドで指定して、フレーズを個人の文法にコミットするのではなく、フレーズの登録を中止することができます。
abort-phrase-enrollment = "Abort-Phrase-Enrollment" ":" BOOLEAN CRLF
abort-phrase-enrollment = "Abort-Phrase-Enrollment" "："ブールCRLF
A recognizer message can carry additional data associated with the request, response, or event. The client MAY provide the grammar to be recognized in DEFINE-GRAMMAR or RECOGNIZE requests. When one or more grammars are specified using the DEFINE-GRAMMAR method, the server MUST attempt to fetch, compile, and optimize the grammar before returning a response to the DEFINE-GRAMMAR method. A RECOGNIZE request MUST completely specify the grammars to be active during the recognition operation, except when the RECOGNIZE method is being used to enroll a grammar. During grammar enrollment, such grammars are OPTIONAL. The server resource sends the recognition results in the RECOGNITION-COMPLETE event and the GET-RESULT response. Grammars and recognition results are carried in the message body of the corresponding MRCPv2 messages.
認識メッセージは、要求、応答、またはイベントに関連付けられた追加のデータを運ぶことができます。クライアントは、DEFINE-GRAMMARまたはRECOGNIZEリクエストで認識される文法を提供してもよい（MAY）。 DEFINE-GRAMMARメソッドを使用して1つ以上の文法が指定されている場合、サーバーは、DEFINE-GRAMMARメソッドへの応答を返す前に、文法のフェッチ、コンパイル、および最適化を試行する必要があります。 RECOGNIZEリクエストは、文法の登録にRECOGNIZEメソッドが使用されている場合を除いて、認識操作中にアクティブになる文法を完全に指定する必要があります。文法の登録中、そのような文法はオプションです。サーバーリソースは、認識結果をRECOGNITION-COMPLETEイベントとGET-RESULT応答で送信します。文法と認識結果は、対応するMRCPv2メッセージのメッセージ本文で伝達されます。
Recognizer grammar data from the client to the server can be provided inline or by reference. Either way, grammar data is carried as typed media entities in the message body of the RECOGNIZE or DEFINE-GRAMMAR request. All MRCPv2 servers MUST accept grammars in the XML form (media type 'application/srgs+xml') of the W3C's XML-based Speech Grammar Markup Format (SRGS) [W3C.REC-speech-grammar-20040316] and MAY accept grammars in other formats. Examples include but are not limited to:
クライアントからサーバーへの認識機能の文法データは、インラインまたは参照によって提供できます。どちらの方法でも、文法データは、RECOGNIZEまたはDEFINE-GRAMMARリクエストのメッセージ本文の型付きメディアエンティティとして伝送されます。すべてのMRCPv2サーバーは、W3CのXMLベースのSpeech Grammar Markup Format（SRGS）[W3C.REC-speech-grammar-20040316]のXML形式（メディアタイプ 'application / srgs + xml'）の文法を受け入れる必要があり、文法を他のフォーマット。例には以下が含まれますが、これらに限定されません。
o the ABNF form (media type 'application/srgs') of SRGS
o SRGSのABNF形式（メディアタイプ 'application / srgs'）
o Sun's Java Speech Grammar Format (JSGF) [refs.javaSpeechGrammarFormat]
o SunのJava Speech Grammar Format（JSGF）[refs.javaSpeechGrammarFormat]
Additionally, MRCPv2 servers MAY support the Semantic Interpretation for Speech Recognition (SISR) [W3C.REC-semantic-interpretation-20070405] specification.
さらに、MRCPv2サーバーは、音声認識の意味解釈（SISR）[W3C.REC-semantic-interpretation-20070405]仕様をサポートする場合があります。
When a grammar is specified inline in the request, the client MUST provide a Content-ID for that grammar as part of the content header fields. If there is no space on the server to store the inline grammar, the request MUST return with a Completion-Cause code of 016 "grammar-definition-failure". Otherwise, the server MUST associate the inline grammar block with that Content-ID and MUST store it on the server for the duration of the session. However, if the Content-ID is redefined later in the session through a subsequent DEFINE-GRAMMAR, the inline grammar previously associated with the Content-ID MUST be freed. If the Content-ID is redefined through a subsequent DEFINE-GRAMMAR with an empty message body (i.e., no grammar definition), then in addition to freeing any grammar previously associated with the Content-ID, the server MUST clear all bindings and associations to the Content-ID. Unless and until subsequently redefined, this URI MUST be interpreted by the server as one that has never been set.
文法がリクエストでインラインで指定されている場合、クライアントはコンテンツヘッダーフィールドの一部としてその文法のContent-IDを提供する必要があります。インラインの文法を格納するスペースがサーバーにない場合、要求は016 "grammar-definition-failure"のCompletion-Causeコードで返される必要があります。それ以外の場合、サーバーはインライン文法ブロックをそのContent-IDに関連付けなければならず（MUST）、セッションの期間中それをサーバーに保存しなければなりません（MUST）。ただし、Content-IDが後続のDEFINE-GRAMMARを通じてセッションの後半で再定義される場合、以前にContent-IDに関連付けられていたインライン文法を解放する必要があります。 Content-IDが後続のDEFINE-GRAMMARを介して空のメッセージ本文（つまり、文法定義なし）で再定義される場合、以前にContent-IDに関連付けられていた文法を解放することに加えて、サーバーはすべてのバインディングと関連付けをクリアする必要があります。 Content-ID。後で再定義されない限り、このURIは、サーバーによって設定されたことがないURIとして解釈される必要があります。
Grammars that have been associated with a Content-ID can be referenced through the 'session' URI scheme (see Section 13.6). For example: session:help@root-level.store
Content-IDに関連付けられている文法は、「セッション」URIスキームを通じて参照できます（セクション13.6を参照）。例：session：help@root-level.store
Grammar data MAY be specified using external URI references. To do so, the client uses a body of media type 'text/uri-list' (see RFC 2483 [RFC2483] ) to list the one or more URIs that point to the grammar data. The client can use a body of media type 'text/ grammar-ref-list' (see Section 13.5.1) if it wants to assign weights to the list of grammar URI. All MRCPv2 servers MUST support grammar access using the 'http' and 'https' URI schemes.
文法データは、外部URI参照を使用して指定できます（MAY）。そのために、クライアントはメディアタイプ「text / uri-list」（RFC 2483 [RFC2483]を参照）の本文を使用して、文法データを指す1つ以上のURIをリストします。クライアントは、文法URIのリストに重みを割り当てたい場合は、メディアタイプ「text / grammar-ref-list」（セクション13.5.1を参照）の本文を使用できます。すべてのMRCPv2サーバーは、「http」および「https」URIスキームを使用した文法アクセスをサポートする必要があります。
If the grammar data the client wishes to be used on a request consists of a mix of URI and inline grammar data, the client uses the 'multipart/mixed' media type to enclose the 'text/uri-list',
クライアントがリクエストで使用したい文法データがURIとインライン文法データの混合で構成されている場合、クライアントは「multipart / mixed」メディアタイプを使用して「text / uri-list」を囲みます。
'application/srgs', or 'application/srgs+xml' content entities. The character set and encoding used in the grammar data are specified using to standard media type definitions.
「application / srgs」または「application / srgs + xml」コンテンツエンティティ。文法データで使用される文字セットとエンコーディングは、標準のメディアタイプ定義を使用して指定されます。
When more than one grammar URI or inline grammar block is specified in a message body of the RECOGNIZE request, the server interprets this as a list of grammar alternatives to match against.
RECOGNIZE要求のメッセージ本文に複数の文法URIまたはインライン文法ブロックが指定されている場合、サーバーはこれを、照合する文法の選択肢のリストとして解釈します。
Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
Content-Type：application / srgs + xml Content-ID：<request1@form-level.store> Content-Length：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- the equivalent single-language attachment expansion -->
<rule id="people2">
<one-of>
<item xml:lang="en-US">Robert</item>
<item xml:lang="fr-CA">Robert</item>
</one-of>
</rule>
</grammar>
SRGS Grammar Example
SRGS文法の例
Content-Type:text/uri-list Content-Length:...
Content-Type：text / uri-list Content-Length：...
session:help@root-level.store
http://www.example.com/Directory-Name-List.grxml
http://www.example.com/Department-List.grxml
http://www.example.com/TAC-Contact-List.grxml
session:menu1@menu-level.store
Grammar Reference Example
文法参考例
Content-Type:multipart/mixed; boundary="break"
--break Content-Type:text/uri-list Content-Length:...
--break Content-Type：text / uri-list Content-Length：...
http://www.example.com/Directory-Name-List.grxml
http://www.example.com/Department-List.grxml
http://www.example.com/TAC-Contact-List.grxml
--break Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
--break Content-Type：application / srgs + xml Content-ID：<request1@form-level.store> Content-Length：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- the equivalent single-language attachment expansion -->
<rule id="people2">
<one-of>
<item xml:lang="en-US">Robert</item>
<item xml:lang="fr-CA">Robert</item>
</one-of>
</rule>
</grammar> --break--
</文法> --break--
Mixed Grammar Reference Example
混合文法リファレンスの例
Recognition results are returned to the client in the message body of the RECOGNITION-COMPLETE event or the GET-RESULT response message as described in Section 6.3. Element and attribute descriptions for the recognition portion of the NLSML format are provided in Section 9.6 with a normative definition of the schema in Section 16.1.
セクション6.3で説明されているように、認識結果はRECOGNITION-COMPLETEイベントのメッセージ本文またはGET-RESULT応答メッセージでクライアントに返されます。 NLSMLフォーマットの認識部分の要素と属性の説明は、セクション16.1のスキーマの規範的な定義とともにセクション9.6に提供されています。
Content-Type:application/nlsml+xml Content-Length:...
Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="http://www.example.com/theYesNoGrammar">
<interpretation>
<instance>
<ex:response>yes</ex:response>
</instance>
<input>OK</input>
</interpretation>
</result>
Result Example
結果の例
Enrollment results are returned to the client in the message body of the RECOGNITION-COMPLETE event as described in Section 6.3. Element and attribute descriptions for the enrollment portion of the NLSML format are provided in Section 9.7 with a normative definition of the schema in Section 16.2.
登録結果は、セクション6.3で説明されているように、RECOGNITION-COMPLETEイベントのメッセージ本文でクライアントに返されます。 NLSML形式の登録部分の要素と属性の説明は、セクション16.2のスキーマの規範的な定義とともにセクション9.7に記載されています。
When a client changes servers while operating on the behalf of the same incoming communication session, this header field allows the client to collect a block of opaque data from one server and provide it to another server. This capability is desirable if the client needs different language support or because the server issued a redirect. Here, the first recognizer resource may have collected acoustic and other data during its execution of recognition methods. After a server switch, communicating this data may allow the recognizer resource on the new server to provide better recognition. This block of data is implementation specific and MUST be carried as media type 'application/octets' in the body of the message.
クライアントが同じ着信通信セッションに代わって動作しているときにサーバーを変更すると、このヘッダーフィールドにより、クライアントは不透明なデータのブロックを1つのサーバーから収集して別のサーバーに提供できます。この機能は、クライアントが異なる言語サポートを必要とする場合、またはサーバーがリダイレクトを発行したために望ましいものです。ここで、最初の認識リソースは、認識方法の実行中に音響データやその他のデータを収集した可能性があります。サーバーの切り替え後、このデータを通信することで、新しいサーバーの認識機能リソースがより適切に認識できるようになります。このデータブロックは実装固有であり、メッセージの本文でメディアタイプ「application / octets」として伝達する必要があります。
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, if any, in the message body as an entity of media type 'application/octets' with a specific Content-ID. The Content-ID value MUST also be specified in the Recognizer-Context-Block header field in the GET-PARAMS response. The SET-PARAMS request wishing to provide this vendor-specific data MUST send it in the message body as a typed entity with the same Content-ID that it received from the GET-PARAMS. The Content-ID MUST also be sent in the Recognizer-Context-Block header field of the SET-PARAMS message.
このデータブロックは、SET-PARAMSおよびGET-PARAMSメソッド/応答メッセージで通信されます。 GET-PARAMSメソッドでは、空のRecognizer-Context-Blockヘッダーフィールドが存在する場合、認識機能は、ベンダー固有のコンテキストブロックがあれば、それをメディアタイプ「application / octets」のエンティティとしてメッセージ本文に返す必要があります（SHOULD）。特定のコンテンツIDを使用します。 Content-ID値は、GET-PARAMS応答のRecognizer-Context-Blockヘッダーフィールドでも指定する必要があります。このベンダー固有のデータを提供したいSET-PARAMSリクエストは、GET-PARAMSから受け取ったものと同じContent-IDを持つ型付きエンティティとしてメッセージ本文で送信する必要があります。 Content-IDは、SET-PARAMSメッセージのRecognizer-Context-Blockヘッダーフィールドでも送信する必要があります。
Each speech recognition implementation choosing to use this mechanism to hand off recognizer context data among servers MUST distinguish its implementation-specific block of data from other implementations by choosing a Content-ID that is recognizable among the participating servers and unlikely to collide with values chosen by another implementation.
このメカニズムを使用してサーバー間で認識機能コンテキストデータをハンドオフすることを選択する各音声認識実装は、参加サーバー間で認識可能であり、別の実装。
The recognizer portion of NLSML (see Section 6.3.1) represents information automatically extracted from a user's utterances by a semantic interpretation component, where "utterance" is to be taken in the general sense of a meaningful user input in any modality supported by the MRCPv2 implementation.
NLSMLの認識機能部分（セクション6.3.1を参照）は、意味解釈コンポーネントによってユーザーの発話から自動的に抽出された情報を表します。ここで、「発話」は、MRCPv2によってサポートされる任意のモダリティでの意味のあるユーザー入力の一般的な意味で解釈されます。実装。
MRCPv2 recognizer resources employ the Natural Language Semantics Markup Language (NLSML) to interpret natural language speech input and to format the interpretation for consumption by an MRCPv2 client.
MRCPv2レコグナイザリソースは、Natural Language Semantics Markup Language（NLSML）を使用して、自然言語の音声入力を解釈し、MRCPv2クライアントが使用する解釈をフォーマットします。
The elements of the markup fall into the following general functional categories: interpretation, side information, and multi-modal integration.
マークアップの要素は、解釈、サイド情報、マルチモーダル統合という一般的な機能カテゴリに分類されます。
Elements and attributes represent the semantics of a user's utterance, including the <result>, <interpretation>, and <instance> elements. The <result> element contains the full result of processing one utterance. It MAY contain multiple <interpretation> elements if the interpretation of the utterance results in multiple alternative meanings due to uncertainty in speech recognition or natural language understanding. There are at least two reasons for providing multiple interpretations:
要素と属性は、<result>、<interpretation>、<instance>要素など、ユーザーの発話のセマンティクスを表します。 <result>要素には、1つの発話を処理した完全な結果が含まれます。音声認識または自然言語理解の不確実性のために、発話の解釈が複数の代替的な意味をもたらす場合、複数の<interpretation>要素を含めることができます。複数の解釈を提供する理由は少なくとも2つあります。
1. The client application might have additional information, for example, information from a database, that would allow it to select a preferred interpretation from among the possible interpretations returned from the semantic interpreter.
1. クライアントアプリケーションには、セマンティックインタープリターから返される可能性のある解釈の中から優先解釈を選択できるようにする追加情報（データベースからの情報など）がある場合があります。
2. A client-based dialog manager (e.g., VoiceXML [W3C.REC-voicexml20-20040316]) that was unable to select between several competing interpretations could use this information to go back to the user and find out what was intended. For example, it could issue a SPEAK request to a synthesizer resource to emit "Did you say 'Boston' or 'Austin'?"
2. いくつかの競合する解釈から選択できないクライアントベースのダイアログマネージャー（VoiceXML [W3C.REC-voicexml20-20040316]など）は、この情報を使用してユーザーに戻り、意図されたものを見つけることができます。たとえば、シンセサイザリソースにSPEAKリクエストを発行して、「ボストンかオースティンか？」
These are elements and attributes representing additional information about the interpretation, over and above the interpretation itself. Side information includes:
これらは、解釈自体に加えて、解釈に関する追加情報を表す要素と属性です。サイド情報は次のとおりです。
1. Whether an interpretation was achieved (the <nomatch> element) and the system's confidence in an interpretation (the "confidence" attribute of <interpretation>).
1. 解釈が達成されたか（<nomatch>要素）、解釈に対するシステムの信頼度（<interpretation>の「confidence」属性）。
2. Alternative interpretations (<interpretation>)
2. 代替解釈（<解釈>）
3. Input formats and Automatic Speech Recognition (ASR) information: the <input> element, representing the input to the semantic interpreter.
3. 入力形式と自動音声認識（ASR）情報：セマンティックインタープリターへの入力を表す<input>要素。
When more than one modality is available for input, the interpretation of the inputs needs to be coordinated. The "mode" attribute of <input> supports this by indicating whether the utterance was input by speech, DTMF, pointing, etc. The "timestamp-start" and "timestamp-end" attributes of <input> also provide for temporal coordination by indicating when inputs occurred.
入力に複数のモダリティが利用可能な場合、入力の解釈を調整する必要があります。 <input>の「mode」属性は、発話が音声、DTMF、ポインティングなどによって入力されたかどうかを示すことによってこれをサポートします。<input>の「timestamp-start」および「timestamp-end」属性は、入力がいつ発生したかを示します。
The recognizer elements in NLSML fall into two categories:
NLSMLの認識要素は2つのカテゴリに分類されます。
1. description of the input that was processed, and
1. 処理された入力の説明、および
2. description of the meaning which was extracted from the input.
2. 入力から抽出された意味の説明。
Next to each element are its attributes. In addition, some elements can contain multiple instances of other elements. For example, a <result> can contain multiple <interpretation> elements, each of which is taken to be an alternative. Similarly, <input> can contain multiple child <input> elements, which are taken to be cumulative. To illustrate the basic usage of these elements, as a simple example, consider the utterance "OK" (interpreted as "yes"). The example illustrates how that utterance and its interpretation would be represented in the NLSML markup.
各要素の隣にはその属性があります。さらに、一部の要素には、他の要素の複数のインスタンスを含めることができます。たとえば、<result>には複数の<interpretation>要素を含めることができ、そのそれぞれが代替と見なされます。同様に、<input>には複数の子<input>要素を含めることができ、それらは累積的であると見なされます。これらの要素の基本的な使用法を説明するために、簡単な例として、「OK」（「yes」と解釈される）という発話を考えてみましょう。この例は、その発話とその解釈がNLSMLマークアップでどのように表されるかを示しています。
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="http://www.example.com/theYesNoGrammar">
<interpretation>
<instance>
<ex:response>yes</ex:response>
</instance>
<input>OK</input>
</interpretation>
</result>
This example includes only the minimum required information. There is an overall <result> element, which includes one interpretation and an input element. The interpretation contains the application-specific element "<response>", which is the semantically interpreted result.
この例には、最低限必要な情報のみが含まれています。 1つの解釈とinput要素を含む全体的な<result>要素があります。解釈には、アプリケーション固有の要素「<response>」が含まれます。これは、意味的に解釈された結果です。
The root element of the markup is <result>. The <result> element includes one or more <interpretation> elements. Multiple interpretations can result from ambiguities in the input or in the semantic interpretation. If the "grammar" attribute does not apply to all of the interpretations in the result, it can be overridden for individual interpretations at the <interpretation> level.
マークアップのルート要素は<result>です。 <result>要素には、1つ以上の<interpretation>要素が含まれます。複数の解釈は、入力またはセマンティック解釈のあいまいさに起因する可能性があります。 「文法」属性が結果のすべての解釈に適用されない場合、<interpretation>レベルで個々の解釈に対してオーバーライドできます。
Attributes:
属性：
1. grammar: The grammar or recognition rule matched by this result. The format of the grammar attribute will match the rule reference semantics defined in the grammar specification. Specifically, the rule reference is in the external XML form for grammar rule references. The markup interpreter needs to know the grammar rule that is matched by the utterance because multiple rules may be simultaneously active. The value is the grammar URI used by the markup interpreter to specify the grammar. The grammar can be overridden by a grammar attribute in the <interpretation> element if the input was ambiguous as to which grammar it matched. If all interpretation elements within the result element contain their own grammar attributes, the attribute can be dropped from the result element.
1. 文法：この結果に一致する文法または認識ルール。文法属性のフォーマットは、文法仕様で定義されているルール参照セマンティクスと一致します。具体的には、ルール参照は、文法ルール参照の外部XML形式です。複数のルールが同時にアクティブになる可能性があるため、マークアップインタープリターは発話と一致する文法ルールを認識する必要があります。値は、マークアップインタープリターが文法を指定するために使用する文法URIです。文法は、入力がどの文法に一致したのかあいまいな場合、<interpretation>要素の文法属性によってオーバーライドできます。結果要素内のすべての解釈要素に独自の文法属性が含まれている場合、属性を結果要素から削除できます。
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="http://www.example.com/grammar">
<interpretation>
....
</interpretation>
</result>
An <interpretation> element contains a single semantic interpretation.
<interpretation>要素には、単一の意味解釈が含まれます。
Attributes:
属性：
1. confidence: A float value from 0.0-1.0 indicating the semantic analyzer's confidence in this interpretation. A value of 1.0 indicates maximum confidence. The values are implementation dependent but are intended to align with the value interpretation for the confidence MRCPv2 header field defined in Section 9.4.1. This attribute is OPTIONAL.
1. Confidence：この解釈に対するセマンティックアナライザーの信頼度を示す0.0〜1.0の浮動小数点値。値1.0は、最大の信頼度を示します。値は実装に依存しますが、セクション9.4.1で定義されている信頼性MRCPv2ヘッダーフィールドの値の解釈に合わせるためのものです。この属性はオプションです。
2. grammar: The grammar or recognition rule matched by this interpretation (if needed to override the grammar specification at the <interpretation> level.) This attribute is only needed under <interpretation> if it is necessary to override a grammar that was defined at the <result> level. Note that the grammar attribute for the interpretation element is optional if and only if the grammar attribute is specified in the <result> element.
2. 文法：この解釈に一致する文法または認識ルール（<interpretation>レベルで文法仕様をオーバーライドする必要がある場合）。この属性は、<interpretation>で、<で定義された文法をオーバーライドする必要がある場合にのみ必要です。結果>レベル。 <result>要素で文法属性が指定されている場合にのみ、解釈要素の文法属性はオプションであることに注意してください。
Interpretations MUST be sorted best-first by some measure of "goodness". The goodness measure is "confidence" if present; otherwise, it is some implementation-specific indication of quality.
解釈は、ある程度の「良さ」の基準で最も優先してソートする必要があります。良さの尺度は、存在する場合は「信頼度」です。それ以外の場合は、実装固有の品質を示すものです。
The grammar is expected to be specified most frequently at the <result> level. However, it can be overridden at the <interpretation> level because it is possible that different interpretations may match different grammar rules.
文法は、<result>レベルで最も頻繁に指定されると予想されます。ただし、異なる解釈が異なる文法規則と一致する可能性があるため、<interpretation>レベルでオーバーライドできます。
The <interpretation> element includes an optional <input> element containing the input being analyzed, and at least one <instance> element containing the interpretation of the utterance.
<interpretation>要素には、分析される入力を含むオプションの<input>要素と、発話の解釈を含む少なくとも1つの<instance>要素が含まれます。
<interpretation confidence="0.75"
grammar="http://www.example.com/grammar">
...
</interpretation>
The <instance> element contains the interpretation of the utterance. When the Semantic Interpretation for Speech Recognition format is used, the <instance> element contains the XML serialization of the result using the approach defined in that specification. When there is semantic markup in the grammar that does not create semantic objects, but instead only does a semantic translation of a portion of the input, such as translating "coke" to "coca-cola", the instance contains the whole input but with the translation applied. The NLSML looks like the markup in Figure 2 below. If there are no semantic objects created, nor any semantic translation, the instance value is the same as the input value.
<instance>要素には、発話の解釈が含まれています。音声認識フォーマットのセマンティック解釈が使用される場合、<instance>要素には、その仕様で定義されているアプローチを使用した結果のXMLシリアル化が含まれます。文法にセマンティックマークアップがあり、セマンティックオブジェクトを作成せず、代わりに「coke」を「coca-cola」に変換するなど、入力の一部の意味変換のみを行う場合、インスタンスには入力全体が含まれますが、適用された翻訳。 NLSMLは、下の図2のマークアップのように見えます。セマンティックオブジェクトが作成されておらず、セマンティックトランスレーションもない場合、インスタンス値は入力値と同じです。
Attributes:
属性：
1. confidence: Each element of the instance MAY have a confidence attribute, defined in the NLSML namespace. The confidence attribute contains a float value in the range from 0.0-1.0 reflecting the system's confidence in the analysis of that slot. A value of 1.0 indicates maximum confidence. The values are implementation dependent, but are intended to align with the value interpretation for the MRCPv2 header field Confidence-Threshold defined in Section 9.4.1. This attribute is OPTIONAL.
1. Confidence：インスタンスの各要素は、NLSML名前空間で定義されたconfidence属性を持つことができます。信頼性属性には、そのスロットの分析におけるシステムの信頼性を反映する0.0〜1.0の範囲の浮動小数値が含まれています。値1.0は、最大の信頼度を示します。値は実装に依存しますが、セクション9.4.1で定義されているMRCPv2ヘッダーフィールドのConfidence-Thresholdの値の解釈に合わせるためのものです。この属性はオプションです。
<instance>
<nameAddress>
<street confidence="0.75">123 Maple Street</street>
<city>Mill Valley</city>
<state>CA</state>
<zip>90952</zip>
</nameAddress>
</instance>
<input>
My address is 123 Maple Street,
Mill Valley, California, 90952
</input>
<instance>
I would like to buy a coca-cola
</instance>
<input>
I would like to buy a coke
</input>
Figure 2: NSLML Example
図2：NSLMLの例
The <input> element is the text representation of a user's input. It includes an optional "confidence" attribute, which indicates the recognizer's confidence in the recognition result (as opposed to the confidence in the interpretation, which is indicated by the "confidence" attribute of <interpretation>). Optional "timestamp-start" and "timestamp-end" attributes indicate the start and end times of a spoken utterance, in ISO 8601 format [ISO.8601.1988].
<input>要素は、ユーザーの入力のテキスト表現です。これには、オプションの「confidence」属性が含まれます。これは、認識結果に対する認識機能の信頼度を示します（解釈の信頼度は<interpretation>の「confidence」属性で示されます）。オプションの「timestamp-start」および「timestamp-end」属性は、ISO 8601形式[ISO.8601.1988]で、発話の開始時間と終了時間を示します。
Attributes:
属性：
1. timestamp-start: The time at which the input began. (optional)
1. timestamp-start：入力が開始された時刻。 （オプション）
2. timestamp-end: The time at which the input ended. (optional)
2. timestamp-end：入力が終了した時刻。 （オプション）
3. mode: The modality of the input, for example, speech, DTMF, etc. (optional)
3. モード：音声、DTMFなどの入力のモダリティ（オプション）
4. confidence: The confidence of the recognizer in the correctness of the input in the range 0.0 to 1.0. (optional)
4. confidence：0.0から1.0の範囲の入力の正確さに対する認識機能の信頼度。 （オプション）
Note that it may not make sense for temporally overlapping inputs to have the same mode; however, this constraint is not expected to be enforced by implementations.
時間的にオーバーラップする入力が同じモードを持つことは意味がないことに注意してください。ただし、この制約は実装によって強制されるとは想定されていません。
When there is no time zone designator, ISO 8601 time representations default to local time.
タイムゾーン指定子がない場合、ISO 8601の時間表現はデフォルトで現地時間になります。
There are three possible formats for the <input> element.
<input>要素には、3つの可能な形式があります。
1. The <input> element can contain simple text:
1. <input>要素には単純なテキストを含めることができます：
<input>onions</input>
A future possibility is for <input> to contain not only text but additional markup that represents prosodic information that was contained in the original utterance and extracted by the speech recognizer. This depends on the availability of ASRs that are capable of producing prosodic information. MRCPv2 clients MUST be prepared to receive such markup and MAY make use of it.
将来の可能性は、<input>にテキストだけでなく、元の発話に含まれ、音声認識機能によって抽出された韻律情報を表す追加のマークアップを含めることです。これは、韻律情報を生成できるASRの可用性に依存します。 MRCPv2クライアントは、そのようなマークアップを受け取る準備ができていなければならず、それを利用してもよい（MAY）。
2. An <input> tag can also contain additional <input> tags. Having additional input elements allows the representation to support future multi-modal inputs as well as finer-grained speech information, such as timestamps for individual words and word-level confidences.
2. <input>タグには、追加の<input>タグを含めることもできます。追加の入力要素があると、表現は将来のマルチモーダル入力だけでなく、個々の単語のタイムスタンプや単語レベルの信頼度など、よりきめ細かい音声情報をサポートできます。
<input>
<input mode="speech" confidence="0.5"
timestamp-start="2000-04-03T0:00:00"
timestamp-end="2000-04-03T0:00:00.2">fried</input>
<input mode="speech" confidence="1.0"
timestamp-start="2000-04-03T0:00:00.25"
timestamp-end="2000-04-03T0:00:00.6">onions</input>
</input>
3. Finally, the <input> element can contain <nomatch> and <noinput> elements, which describe situations in which the speech recognizer received input that it was unable to process or did not receive any input at all, respectively.
3. 最後に、<input>要素には、<nomatch>要素と<noinput>要素を含めることができます。これらの要素は、それぞれ音声認識機能が処理できない入力を受け取った、またはまったく入力を受け取っていない状況を示します。
The <nomatch> element under <input> is used to indicate that the semantic interpreter was unable to successfully match any input with confidence above the threshold. It can optionally contain the text of the best of the (rejected) matches.
<input>の下の<nomatch>要素は、セマンティックインタープリターがしきい値を超える信頼度で入力を正常に照合できなかったことを示すために使用されます。必要に応じて、（拒否された）一致のうち最も良いもののテキストを含めることができます。
<interpretation>
<instance/>
<input confidence="0.1">
<nomatch/>
</input>
</interpretation>
<interpretation>
<instance/>
<input mode="speech" confidence="0.1">
<nomatch>I want to go to New York</nomatch>
</input>
</interpretation>
<noinput> indicates that there was no input -- a timeout occurred in
the speech recognizer due to silence.
<interpretation>
<instance/>
<input>
<noinput/>
</input>
</interpretation>
If there are multiple levels of inputs, the most natural place for
<nomatch> and <noinput> elements to appear is under the highest level
of <input> for <noinput>, and under the appropriate level of
<interpretation> for <nomatch>. So, <noinput> means "no input at
all" and <nomatch> means "no match in speech modality" or "no match
in DTMF modality". For example, to represent garbled speech combined
with DTMF "1 2 3 4", the markup would be:
<input>
<input mode="speech"><nomatch/></input>
<input mode="dtmf">1 2 3 4</input>
</input>
Note: while <noinput> could be represented as an attribute of input, <nomatch> cannot, since it could potentially include PCDATA content with the best match. For parallelism, <noinput> is also an element.
注：<noinput>はinputの属性として表すことができますが、<nomatch>は、最も一致するPCDATAコンテンツを含む可能性があるため、できません。並列処理の場合、<noinput>も要素です。
All enrollment elements are contained within a single <enrollment-result> element under <result>. The elements are described below and have the schema defined in Section 16.2. The following elements are defined:
すべての登録要素は、<result>の下の単一の<enrollment-result>要素内に含まれています。要素については以下で説明し、セクション16.2で定義されているスキーマを使用します。次の要素が定義されています。
1. num-clashes
1. num-clashes
2. num-good-repetitions
2. num-good-repetitions
3. num-repetitions-still-needed
3. num-repetitions-need-needed
4. consistency-status
4. 整合性ステータス
5. clash-phrase-ids
5. クラッシュフレーズID
6. transcriptions
6. 文字起こし
7. confusable-phrases
7. 紛らわしいフレーズ
The <num-clashes> element contains the number of clashes that this pronunciation has with other pronunciations in an active enrollment session. The associated Clash-Threshold header field determines the sensitivity of the clash measurement. Note that clash testing can be turned off completely by setting the Clash-Threshold header field value to 0.
<num-clashes>要素には、アクティブな登録セッションで、この発音と他の発音との衝突の数が含まれています。関連するClash-Thresholdヘッダーフィールドは、干渉測定の感度を決定します。 Clash-Thresholdヘッダーフィールドの値を0に設定すると、クラッシュテストを完全にオフにできることに注意してください。
The <num-good-repetitions> element contains the number of consistent pronunciations obtained so far in an active enrollment session.
<num-good-repetitions>要素には、アクティブな登録セッションでこれまでに得られた一貫した発音の数が含まれています。
The <num-repetitions-still-needed> element contains the number of consistent pronunciations that must still be obtained before the new phrase can be added to the enrollment grammar. The number of consistent pronunciations required is specified by the client in the request header field Num-Min-Consistent-Pronunciations. The returned value must be 0 before the client can successfully commit a phrase to the grammar by ending the enrollment session.
<num-repetitions-still-needed>要素には、新しいフレーズを登録文法に追加する前に取得する必要がある一貫した発音の数が含まれています。必要な一貫した発音の数は、要求ヘッダーフィールドNum-Min-Consistent-Pronunciationsでクライアントによって指定されます。クライアントが登録セッションを終了して文法にフレーズを正常にコミットする前に、戻り値は0でなければなりません。
The <consistency-status> element is used to indicate how consistent the repetitions are when learning a new phrase. It can have the values of consistent, inconsistent, and undecided.
<consistency-status>要素は、新しいフレーズを学習するときの繰り返しの一貫性を示すために使用されます。一貫性のある値、一貫性のない値、および未決定の値を持つことができます。
The <clash-phrase-ids> element contains the phrase IDs of clashing pronunciation(s), if any. This element is absent if there are no clashes.
<clash-phrase-ids>要素には、衝突する発音のフレーズIDが含まれます（ある場合）。衝突がない場合、この要素はありません。
The <transcriptions> element contains the transcriptions returned in the last repetition of the phrase being enrolled.
<transcriptions>要素には、登録されているフレーズの最後の繰り返しで返された文字起こしが含まれます。
The <confusable-phrases> element contains a list of phrases from a command grammar that are confusable with the phrase being added to the personal grammar. This element MAY be absent if there are no confusable phrases.
<confusable-phrases>要素には、パーソナル文法に追加されるフレーズと混同される可能性があるコマンド文法のフレーズのリストが含まれています。この要素は、紛らわしいフレーズがない場合は存在しない場合があります。
The DEFINE-GRAMMAR method, from the client to the server, provides one or more grammars and requests the server to access, fetch, and compile the grammars as needed. The DEFINE-GRAMMAR method implementation MUST do a fetch of all external URIs that are part of that operation. If caching is implemented, this URI fetching MUST conform to the cache control hints and parameter header fields associated with the method in deciding whether the URIs should be fetched from cache or from the external server. If these hints/ parameters are not specified in the method, the values set for the session using SET-PARAMS/GET-PARAMS apply. If it was not set for the session, their default values apply.
クライアントからサーバーへのDEFINE-GRAMMARメソッドは、1つ以上の文法を提供し、必要に応じてサーバーに文法へのアクセス、フェッチ、およびコンパイルを要求します。 DEFINE-GRAMMARメソッドの実装は、その操作の一部であるすべての外部URIのフェッチを実行する必要があります。キャッシングが実装されている場合、このURIフェッチは、URIをキャッシュからフェッチするか外部サーバーからフェッチするかを決定する際に、メソッドに関連付けられたキャッシュコントロールヒントおよびパラメーターヘッダーフィールドに準拠する必要があります。これらのヒント/パラメーターがメソッドで指定されていない場合、SET-PARAMS / GET-PARAMSを使用してセッションに設定された値が適用されます。セッションに設定されていない場合は、デフォルト値が適用されます。
If the server resource is in the recognition state, the DEFINE-GRAMMAR request MUST respond with a failure status.
サーバーリソースが認識状態にある場合、DEFINE-GRAMMARリクエストは失敗ステータスで応答する必要があります。
If the resource is in the idle state and is able to successfully process the supplied grammars, the server MUST return a success code status and the request-state MUST be COMPLETE.
リソースがアイドル状態にあり、提供された文法を正常に処理できる場合、サーバーは成功コードステータスを返さなければならず、要求状態は完全でなければなりません（MUST）。
If the recognizer resource could not define the grammar for some reason (for example, if the download failed, the grammar failed to compile, or the grammar was in an unsupported form), the MRCPv2 response for the DEFINE-GRAMMAR method MUST contain a failure status-code of 407 and contain a Completion-Cause header field describing the failure reason.
認識機能リソースが何らかの理由で文法を定義できなかった場合（たとえば、ダウンロードが失敗した、文法がコンパイルに失敗した、または文法がサポートされていない形式であった）場合、DEFINE-GRAMMARメソッドのMRCPv2応答に失敗が含まれている必要がありますstatus-codeは407で、失敗の理由を説明するCompletion-Causeヘッダーフィールドが含まれています。
C->S:MRCP/2.0 ... DEFINE-GRAMMAR 543257 Channel-Identifier:32AECB23433801@speechrecog Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... DEFINE-GRAMMAR 543257 Channel-Identifier：32AECB23433801 @ speechrecog Content-Type：application / srgs + xml Content-ID：<request1@form-level.store> Content-Length :. 。
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/2.0 ... 543257 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
Completion-Cause:000 success
C->S:MRCP/2.0 ... DEFINE-GRAMMAR 543258 Channel-Identifier:32AECB23433801@speechrecog Content-Type:application/srgs+xml Content-ID:<helpgrammar@root-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... DEFINE-GRAMMAR 543258 Channel-Identifier：32AECB23433801 @ speechrecog Content-Type：application / srgs + xml Content-ID：<helpgrammar@root-level.store> Content-Length :. 。
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
S->C:MRCP/2.0 ... 543258 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
Completion-Cause:000 success
C->S:MRCP/2.0 ... DEFINE-GRAMMAR 543259 Channel-Identifier:32AECB23433801@speechrecog Content-Type:application/srgs+xml Content-ID:<request2@field-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... DEFINE-GRAMMAR 543259 Channel-Identifier：32AECB23433801 @ speechrecog Content-Type：application / srgs + xml Content-ID：<request2@field-level.store> Content-Length :. 。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
"http://www.w3.org/TR/speech-grammar/grammar.dtd">
<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/06/grammar
http://www.w3.org/TR/speech-grammar/grammar.xsd"
version="1.0" mode="voice" root="basicCmd">
<meta name="author" content="Stephanie Williams"/>
<rule id="basicCmd" scope="public">
<example> please move the window </example>
<example> open a file </example>
<ruleref
uri="http://grammar.example.com/politeness.grxml#startPolite"/>
<ruleref uri="#command"/>
<ruleref
uri="http://grammar.example.com/politeness.grxml#endPolite"/>
</rule>
<rule id="command">
<ruleref uri="#action"/> <ruleref uri="#object"/>
</rule>
<rule id="action">
<one-of>
<item weight="10"> open <tag>open</tag> </item>
<item weight="2"> close <tag>close</tag> </item>
<item weight="1"> delete <tag>delete</tag> </item>
<item weight="1"> move <tag>move</tag> </item>
</one-of>
</rule>
<rule id="object">
<item repeat="0-1">
<one-of>
<item> the </item>
<item> a </item>
</one-of>
</item>
<one-of>
<item> window </item>
<item> file </item>
<item> menu </item>
</one-of>
</rule>
</grammar>
S->C:MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
Completion-Cause:000 success
C->S:MRCP/2.0 ... RECOGNIZE 543260 Channel-Identifier:32AECB23433801@speechrecog N-Best-List-Length:2 Content-Type:text/uri-list Content-Length:...
C-> S：MRCP / 2.0 ... RECOGNIZE 543260 Channel-Identifier：32AECB23433801 @ speechrecog N-Best-List-Length：2 Content-Type：text / uri-list Content-Length：...
session:request1@form-level.store
session:request2@field-level.store
session:helpgramar@root-level.store
S->C:MRCP/2.0 ... 543260 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C:MRCP/2.0 ... START-OF-INPUT 543260 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C:MRCP/2.0 ... RECOGNITION-COMPLETE 543260 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Waveform-URI:<http://web.media.com/session123/audio.wav>; size=124535;duration=2340 Content-Type:application/x-nlsml Content-Length:...
S-> C：MRCP / 2.0 ... RECOGNITION-COMPLETE 543260 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Waveform-URI：<http://web.media.com/session123/audio.wav> ; size = 124535; duration = 2340 Content-Type：application / x-nlsml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Define Grammar Example
文法例の定義
The RECOGNIZE method from the client to the server requests the recognizer to start recognition and provides it with one or more grammar references for grammars to match against the input media. The RECOGNIZE method can carry header fields to control the sensitivity, confidence level, and the level of detail in results provided by the recognizer. These header field values override the current values set by a previous SET-PARAMS method.
クライアントからサーバーへのRECOGNIZEメソッドは、認識機能に認識の開始を要求し、入力メディアと照合するための文法の1つ以上の文法参照を提供します。 RECOGNIZEメソッドは、ヘッダーフィールドを伝送して、認識機能によって提供される結果の感度、信頼レベル、および詳細レベルを制御できます。これらのヘッダーフィールド値は、以前のSET-PARAMSメソッドによって設定された現在の値をオーバーライドします。
The RECOGNIZE method can request the recognizer resource to operate in normal or hotword mode as specified by the Recognition-Mode header field. The default value is "normal". If the resource could not start a recognition, the server MUST respond with a failure status- code of 407 and a Completion-Cause header field in the response describing the cause of failure.
RECOGNIZEメソッドは、Recognition-Modeヘッダーフィールドで指定された通常モードまたはホットワードモードで動作するように認識リソースを要求できます。デフォルト値は「通常」です。リソースが認識を開始できなかった場合、サーバーは、失敗ステータスコード407と、失敗の原因を説明する応答のCompletion-Causeヘッダーフィールドで応答する必要があります。
The RECOGNIZE request uses the message body to specify the grammars applicable to the request. The active grammar(s) for the request can be specified in one of three ways. If the client needs to explicitly control grammar weights for the recognition operation, it MUST employ method 3 below. The order of these grammars specifies the precedence of the grammars that is used when more than one grammar in the list matches the speech; in this case, the grammar with the higher precedence is returned as a match. This precedence capability is useful in applications like VoiceXML browsers to order grammars specified at the dialog, document, and root level of a VoiceXML application.
RECOGNIZE要求は、メッセージ本文を使用して、要求に適用可能な文法を指定します。リクエストのアクティブな文法は、3つの方法のいずれかで指定できます。クライアントが認識操作の文法の重みを明示的に制御する必要がある場合は、以下の方法3を使用する必要があります。これらの文法の順序は、リスト内の複数の文法が音声に一致する場合に使用される文法の優先順位を指定します。この場合、優先順位の高い文法が一致として返されます。この優先機能は、VoiceXMLブラウザーなどのアプリケーションで、VoiceXMLアプリケーションのダイアログ、ドキュメント、およびルートレベルで指定された文法を順序付けるのに役立ちます。
1. The grammar MAY be placed directly in the message body as typed content. If more than one grammar is included in the body, the order of inclusion controls the corresponding precedence for the grammars during recognition, with earlier grammars in the body having a higher precedence than later ones.
1. 文法は、タイプされたコンテンツとしてメッセージ本文に直接配置できます。本文に複数の文法が含まれている場合、挿入の順序によって認識中の文法の対応する優先順位が制御され、本文の初期の文法は後の文法よりも優先順位が高くなります。
2. The body MAY contain a list of grammar URIs specified in content of media type 'text/uri-list' [RFC2483]. The order of the URIs determines the corresponding precedence for the grammars during recognition, with highest precedence first and decreasing for each URI thereafter.
2. 本文には、メディアタイプ 'text / uri-list' [RFC2483]のコンテンツで指定された文法URIのリストを含めることができます（MAY）。 URIの順序は、認識中に文法の対応する優先順位を決定します。最初に最も高い優先順位が、その後は各URIで減少します。
3. The body MAY contain a list of grammar URIs specified in content of media type 'text/grammar-ref-list'. This type defines a list of grammar URIs and allows each grammar URI to be assigned a weight in the list. This weight has the same meaning as the weights described in Section 2.4.1 of the Speech Grammar Markup Format (SRGS) [W3C.REC-speech-grammar-20040316].
3. 本文には、メディアタイプ「text / grammar-ref-list」のコンテンツで指定された文法URIのリストを含めることができます。このタイプは、文法URIのリストを定義し、リスト内の各文法URIに重みを割り当てることができます。この重みは、Speech Grammar Markup Format（SRGS）[W3C.REC-speech-grammar-20040316]のセクション2.4.1で説明されている重みと同じ意味です。
In addition to performing recognition on the input, the recognizer MUST also enroll the collected utterance in a personal grammar if the Enroll-Utterance header field is set to true and an Enrollment is active (via an earlier execution of the START-PHRASE-ENROLLMENT method). If so, and if the RECOGNIZE request contains a Content-ID header field, then the resulting grammar (which includes the personal grammar as a sub-grammar) can be referenced through the 'session' URI scheme (see Section 13.6).
入力で認識を実行することに加えて、認識機能は、Enroll-Utteranceヘッダーフィールドがtrueに設定され、登録がアクティブな場合に、収集された発話を個人の文法に登録する必要があります（START-PHRASE-ENROLLMENTメソッドの以前の実行を介して） ）。その場合、およびRECOGNIZE要求にContent-IDヘッダーフィールドが含まれている場合、結果の文法（個人文法をサブ文法として含む）は、「セッション」URIスキームを通じて参照できます（セクション13.6を参照）。
If the resource was able to successfully start the recognition, the server MUST return a success status-code and a request-state of IN-PROGRESS. This means that the recognizer is active and that the client MUST be prepared to receive further events with this request-id.
リソースが認識を正常に開始できた場合、サーバーは成功ステータスコードとリクエスト状態IN-PROGRESSを返す必要があります。これは、認識機能がアクティブであり、クライアントがこのリクエストIDでさらにイベントを受信する準備ができている必要があることを意味します。
If the resource was able to queue the request, the server MUST return a success code and request-state of PENDING. This means that the recognizer is currently active with another request and that this request has been queued for processing.
リソースが要求をキューに入れることができた場合、サーバーは成功コードとPENDINGの要求状態を返す必要があります。これは、認識機能が現在別の要求でアクティブであり、この要求が処理のためにキューに入れられていることを意味します。
If the resource could not start a recognition, the server MUST respond with a failure status-code of 407 and a Completion-Cause header field in the response describing the cause of failure.
リソースが認識を開始できなかった場合、サーバーは、失敗ステータスコード407と、失敗の原因を説明する応答内のCompletion-Causeヘッダーフィールドで応答する必要があります。
For the recognizer resource, RECOGNIZE and INTERPRET are the only requests that return a 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 timeout without a match or for some other reason, the recognizer resource MUST send the client a RECOGNITION-COMPLETE event (or INTERPRETATION-COMPLETE, if INTERPRET was the request) with the result of the recognition and a request-state of COMPLETE.
認識リソースの場合、RECOGNIZEおよびINTERPRETは、IN-PROGRESSのrequest-stateを返す唯一の要求です。つまり、認識が進行中であることを意味します。代替の文法の1つに一致するか、一致しないタイムアウトまたはその他の理由で認識が完了した場合、認識リソースはクライアントにRECOGNITION-COMPLETEイベント（またはINTERPRETATIONが要求の場合はINTERPRETATION-COMPLETE）を送信する必要があります。認識の結果およびCOMPLETEの要求状態。
Large grammars can take a long time for the server to compile. For grammars that are used repeatedly, the client can improve server performance by issuing 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' URI scheme (see Section 13.6). This also applies in general if the client wants to repeat recognition with a previous inline grammar.
大きな文法は、サーバーのコンパイルに時間がかかる場合があります。繰り返し使用される文法の場合、クライアントは事前に文法を含むDEFINE-GRAMMAR要求を発行することにより、サーバーのパフォーマンスを向上させることができます。このような場合、クライアントはRECOGNIZE要求を発行し、「セッション」URIスキームを介して文法を参照できます（セクション13.6を参照）。これは、クライアントが以前のインライン文法で認識を繰り返したい場合にも一般的に当てはまります。
The RECOGNIZE method implementation MUST do a fetch of all external URIs that are part of that operation. If caching is implemented, this URI fetching MUST conform to the cache control hints and parameter header fields associated with the method in deciding whether it should be fetched from cache or from the external server. If these hints/parameters are not specified in the method, the values set for the session using SET-PARAMS/GET-PARAMS apply. If it was not set for the session, their default values apply.
RECOGNIZEメソッドの実装は、その操作の一部であるすべての外部URIのフェッチを実行する必要があります。キャッシングが実装されている場合、このURIフェッチは、メソッドをキャッシュから取得するか外部サーバーから取得するかを決定する際に、メソッドに関連付けられたキャッシュコントロールヒントとパラメーターヘッダーフィールドに準拠する必要があります。これらのヒント/パラメーターがメソッドで指定されていない場合、SET-PARAMS / GET-PARAMSを使用してセッションに設定された値が適用されます。セッションに設定されていない場合は、デフォルト値が適用されます。
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 an audio flow is started by the client at the same time as the RECOGNIZE method is sent, either the audio or the RECOGNIZE can arrive at the recognizer first. As another example, the client may choose to continuously send audio to the server and signal the server to recognize using the RECOGNIZE method. Mechanisms to resolve this condition are outside the scope of this specification. The recognizer can expect the media to start flowing when it receives the RECOGNIZE request, but it MUST NOT buffer anything it receives beforehand in order to preserve the semantics that application authors expect with respect to the input timers.
オーディオとメッセージは別々の通信パスを介して伝送されるため、オーディオのフローの開始とRECOGNIZEメソッドの受信の間に競合状態が発生する可能性があることに注意してください。たとえば、RECOGNIZEメソッドが送信されると同時にクライアントによってオーディオフローが開始された場合、オーディオまたはRECOGNIZEのどちらかが最初に認識エンジンに到着する可能性があります。別の例として、クライアントは、音声をサーバーに継続的に送信し、サーバーに信号を送って、認識方法を使用して認識させることを選択できます。この状態を解決するメカニズムは、この仕様の範囲外です。認識エンジンは、メディアがRECOGNIZE要求を受け取ったときにフローを開始することを期待できますが、アプリケーション作成者が入力タイマーに関して期待するセマンティクスを保持するために、事前に受け取ったものをバッファリングしてはなりません。
When a RECOGNIZE method has been received, the recognition is initiated on the stream. The No-Input-Timer MUST be started at this time if the Start-Input-Timers header field is specified as "true". If this header field is set to "false", the No-Input-Timer MUST be started when it receives the START-INPUT-TIMERS method from the client. The Recognition-Timeout MUST be started when the recognition resource detects speech or a DTMF digit in the media stream.
RECOGNIZEメソッドが受信されると、ストリームで認識が開始されます。 Start-Input-Timersヘッダーフィールドが「true」に指定されている場合、この時点でNo-Input-Timerを開始する必要があります。このヘッダーフィールドが「false」に設定されている場合、クライアントからSTART-INPUT-TIMERSメソッドを受信したときにNo-Input-Timerを開始する必要があります。認識リソースがメディアストリームで音声またはDTMFディジットを検出したときに、認識タイムアウトを開始する必要があります。
For recognition when not in hotword mode:
起動ワードモードでない場合の認識：
When the recognizer resource detects speech or a DTMF digit in the media stream, it MUST send the START-OF-INPUT event. When enough speech has been collected for the server to process, the recognizer can try to match the collected speech with the active grammars. If the speech collected at this point fully matches with any of the active grammars, the Speech-Complete-Timer is started. If it matches partially with one or more of the active grammars, with more speech needed before a full match is achieved, then the Speech-Incomplete-Timer is started.
認識リソースが音声またはメディアストリーム内のDTMFディジットを検出すると、START-OF-INPUTイベントを送信する必要があります。サーバーが処理するのに十分なスピーチが収集されると、認識機能は収集されたスピーチをアクティブな文法と照合しようとします。この時点で収集されたスピーチがアクティブな文法のいずれかに完全に一致する場合、Speech-Complete-Timerが開始されます。 1つ以上のアクティブな文法と部分的に一致し、完全な一致が達成される前にさらに音声が必要な場合、Speech-Incomplete-Timerが開始されます。
1. When the No-Input-Timer expires, the recognizer MUST complete with a Completion-Cause code of "no-input-timeout".
1. No-Input-Timerが期限切れになると、認識機能は「no-input-timeout」のCompletion-Causeコードで完了する必要があります。
2. The recognizer MUST support detecting a no-match condition upon detecting end of speech. The recognizer MAY support detecting a no-match condition before waiting for end-of-speech. If this is supported, this capability is enabled by setting the Early-No-Match header field to "true". Upon detecting a no-match condition, the RECOGNIZE MUST return with "no-match".
2. 認識エンジンは、音声の終わりを検出すると、一致しない条件の検出をサポートする必要があります。認識機能は、音声の終わりを待つ前に、一致しない条件の検出をサポートしてもよい（MAY）。これがサポートされている場合、Early-No-Matchヘッダーフィールドを「true」に設定することにより、この機能が有効になります。一致しない条件を検出すると、認識は「一致しない」で返らなければなりません。
3. When the Speech-Incomplete-Timer expires, the recognizer SHOULD complete with a Completion-Cause code of "partial-match", unless the recognizer cannot differentiate a partial-match, in which case it MUST return a Completion-Cause code of "no-match". The recognizer MAY return results for the partially matched grammar.
3. Speech-Incomplete-Timerが期限切れになると、認識エンジンは、部分一致を区別できない場合を除いて、「部分一致」の完了原因コードで完了する必要があります。その場合、認識プログラムは、「no -一致"。認識エンジンは、部分的に一致する文法の結果を返す場合があります。
4. When the Speech-Complete-Timer expires, the recognizer MUST complete with a Completion-Cause code of "success".
4. Speech-Complete-Timerが期限切れになると、認識エンジンはCompletion-Causeコードで「成功」を完了する必要があります。
5. When the Recognition-Timeout expires, one of the following MUST happen:
5. 認識タイムアウトの期限が切れると、次のいずれかが発生する必要があります。
5.1. If there was a partial-match, the recognizer SHOULD complete with a Completion-Cause code of "partial-match-maxtime", unless the recognizer cannot differentiate a partial-match, in which case it MUST complete with a Completion-Cause code of "no-match-maxtime". The recognizer MAY return results for the partially matched grammar.
5.1. 部分一致があった場合、認識機能は、部分一致を区別できない場合を除いて、「部分一致-最大時間」の完了原因コードで完了する必要があります。その場合、認識機能は、部分一致コードで完了する必要があります。 「no-match-maxtime」。認識エンジンは、部分的に一致する文法の結果を返す場合があります。
5.2. If there was a full-match, the recognizer MUST complete with a Completion-Cause code of "success-maxtime".
5.2. 完全一致があった場合、レコグナイザは「成功最大時間」の完了原因コードで完了する必要があります。
5.3. If there was a no match, the recognizer MUST complete with a Completion-Cause code of "no-match-maxtime".
5.3. 一致しなかった場合、認識機能は、「no-match-maxtime」の完了原因コードで完了する必要があります。
For recognition in hotword mode:
起動ワードモードでの認識の場合：
Note that for recognition in hotword mode the START-OF-INPUT event is not generated when speech or a DTMF digit is detected.
ホットワードモードでの認識では、音声またはDTMFディジットが検出された場合、START-OF-INPUTイベントは生成されないことに注意してください。
1. When the No-Input-Timer expires, the recognizer MUST complete with a Completion-Cause code of "no-input-timeout".
1. No-Input-Timerが期限切れになると、認識機能は「no-input-timeout」のCompletion-Causeコードで完了する必要があります。
2. If at any point a match occurs, the RECOGNIZE MUST complete with a Completion-Cause code of "success".
2. いずれかの時点で一致が発生した場合、認識は「成功」の完了原因コードで完了する必要があります。
3. When the Recognition-Timeout expires and there is not a match, the RECOGNIZE MUST complete with a Completion-Cause code of "hotword-maxtime".
3. 認識タイムアウトの期限が切れて一致しない場合、認識は「hotword-maxtime」の完了原因コードで完了する必要があります。
4. When the Recognition-Timeout expires and there is a match, the RECOGNIZE MUST complete with a Completion-Cause code of "success-maxtime".
4. 認識タイムアウトの期限が切れて一致する場合、認識は「成功の最大時間」の完了原因コードで完了する必要があります。
5. When the Recognition-Timeout is running but the detected speech/ DTMF has not resulted in a match, the Recognition-Timeout MUST be stopped and reset. It MUST then be restarted when speech/DTMF is again detected.
5. 認識タイムアウトが実行されているが、検出された音声/ DTMFが一致しない場合は、認識タイムアウトを停止してリセットする必要があります。その後、音声/ DTMFが再度検出されたときに再起動する必要があります。
Below is a complete example of using RECOGNIZE. It shows the call to RECOGNIZE, the IN-PROGRESS and START-OF-INPUT status messages, and the final RECOGNITION-COMPLETE message containing the result.
以下は、認識の完全な使用例です。 RECOGNIZEへの呼び出し、IN-PROGRESSおよびSTART-OF-INPUTステータスメッセージ、結果を含む最後のRECOGNITION-COMPLETEメッセージが表示されます。
C->S:MRCP/2.0 ... RECOGNIZE 543257 Channel-Identifier:32AECB23433801@speechrecog Confidence-Threshold:0.9 Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... RECOGNIZE 543257 Channel-Identifier：32AECB23433801 @ speechrecog Confidence-Threshold：0.9 Content-Type：application / srgs + xml Content-ID：<request1@form-level.store> Content-Length ：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C:MRCP/2.0 ... START-OF-INPUT 543257 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C:MRCP/2.0 ... RECOGNITION-COMPLETE 543257 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Waveform-URI:<http://web.media.com/session123/audio.wav>; size=424252;duration=2543 Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... RECOGNITION-COMPLETE 543257 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Waveform-URI：<http://web.media.com/session123/audio.wav> ; size = 424252; duration = 2543 Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Below is an example of calling RECOGNIZE with a different grammar. No status or completion messages are shown in this example, although they would of course occur in normal usage.
以下は、異なる文法でRECOGNIZEを呼び出す例です。この例ではステータスメッセージや完了メッセージは表示されませんが、通常の使用では当然発生します。
C->S: MRCP/2.0 ... RECOGNIZE 543257 Channel-Identifier:32AECB23433801@speechrecog Confidence-Threshold:0.9 Fetch-Timeout:20 Content-Type:application/srgs+xml Content-Length:...
C-> S：MRCP / 2.0 ... RECOGNIZE 543257 Channel-Identifier：32AECB23433801 @ speechrecog Confidence-Threshold：0.9 Fetch-Timeout：20 Content-Type：application / srgs + xml Content-Length：...
<?xml version="1.0"? Version="1.0" mode="voice"
root="Basic md">
<rule id="rule_list" scope="public">
<one-of>
<item weight=10>
<ruleref uri=
"http://grammar.example.com/world-cities.grxml#canada"/>
</item>
<item weight=1.5>
<ruleref uri=
"http://grammar.example.com/world-cities.grxml#america"/>
</item>
<item weight=0.5>
<ruleref uri=
"http://grammar.example.com/world-cities.grxml#india"/>
</item>
</one-of>
</rule>
The STOP method from the client to the server tells the resource to stop recognition if a request is active. If a RECOGNIZE request is active and the STOP request successfully terminated it, then the response header section 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 is 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, the response MUST contain a status-code of 200 "Success".
クライアントからサーバーへのSTOPメソッドは、要求がアクティブな場合に認識を停止するようにリソースに指示します。 RECOGNIZE要求がアクティブで、STOP要求がそれを正常に終了した場合、応答ヘッダーセクションには、終了したRECOGNIZE要求の要求IDを含むActive-Request-Id-Listヘッダーフィールドが含まれます。この場合、終了したリクエストに対してRECOGNITION-COMPLETEイベントは送信されません。アクティブな認識がなかった場合、応答にはActive-Request-Id-Listヘッダーフィールドを含めてはなりません（MUST NOT）。どちらの方法でも、応答には200 "成功"のステータスコードが含まれている必要があります。
C->S: MRCP/2.0 ... RECOGNIZE 543257 Channel-Identifier:32AECB23433801@speechrecog Confidence-Threshold:0.9 Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... RECOGNIZE 543257 Channel-Identifier：32AECB23433801 @ speechrecog Confidence-Threshold：0.9 Content-Type：application / srgs + xml Content-ID：<request1@form-level.store> Content-Length ：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
C->S: MRCP/2.0 ... STOP 543258 200
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... 543258 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
Active-Request-Id-List:543257
The GET-RESULT method from the client to the server MAY be issued when the recognizer resource 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 server receives this request, it re-computes and returns the results according to the recognition constraints provided in the GET-RESULT request.
The GET-RESULT method from the client to the server MAY be issued when the recognizer resource 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 server receives this request, it re-computes and returns the results according to the recognition constraints provided in the GET-RESULT request.
The GET-RESULT request can specify constraints such as a different confidence-threshold or n-best-list-length. This capability is OPTIONAL for MRCPv2 servers and the automatic speech recognition engine in the server MUST return a status of unsupported feature if not supported.
GET-RESULT要求では、異なる信頼しきい値やn-ベストリスト長などの制約を指定できます。この機能はMRCPv2サーバーではオプションであり、サーバーの自動音声認識エンジンは、サポートされていない場合、サポートされていない機能のステータスを返す必要があります。
C->S: MRCP/2.0 ... GET-RESULT 543257
Channel-Identifier:32AECB23433801@speechrecog
Confidence-Threshold:0.9
S->C: MRCP/2.0 ... 543257 200 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... 543257 200 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
This is an event from the server to the client indicating that the recognizer resource has detected speech or a DTMF digit in the media stream. This event is useful in implementing kill-on-barge-in scenarios when a synthesizer resource is in a different session from the recognizer resource and hence is not aware of an incoming audio source (see Section 8.4.2). In these cases, it is up to the client to act as an intermediary and respond to this event by issuing a BARGE-IN-OCCURRED event to the synthesizer resource. The recognizer resource also MUST send a Proxy-Sync-Id header field with a unique value for this event.
これは、サーバーからクライアントへのイベントであり、認識リソースがメディアストリームで音声またはDTMFディジットを検出したことを示します。このイベントは、シンセサイザリソースが認識リソースとは別のセッションにあり、着信オーディオソースを認識していない場合（セクション8.4.2を参照）、キルオンバージインシナリオの実装に役立ちます。これらの場合、仲介者として機能し、シンセサイザーリソースにBARGE-IN-OCCURREDイベントを発行することにより、このイベントに応答するのはクライアントの責任です。認識リソースは、このイベントの一意の値を含むProxy-Sync-Idヘッダーフィールドも送信する必要があります。
This event MUST be generated by the server, irrespective of whether or not the synthesizer and recognizer are on the same server.
このイベントは、シンセサイザとレコグナイザが同じサーバー上にあるかどうかに関係なく、サーバーによって生成される必要があります。
This request is sent from the client to the recognizer resource when it knows that a kill-on-barge-in prompt has finished playing (see Section 8.4.2). This is useful in the scenario when the recognition and synthesizer engines are not in the same session. When a kill-on-barge-in prompt is being played, the client may want a RECOGNIZE request to be simultaneously active so that it can detect and implement kill-on-barge-in. But at the same time the client doesn't want the recognizer to start the no-input timers until the prompt is finished. The Start-Input-Timers header field in the RECOGNIZE request allows the client to say whether or not the timers should be started immediately. If not, the recognizer resource MUST NOT start the timers until the client sends a START-INPUT-TIMERS method to the recognizer.
このリクエストは、kill-on-barge-inプロンプトの再生が終了したことがわかったときに、クライアントから認識リソースに送信されます（セクション8.4.2を参照）。これは、認識エンジンとシンセサイザエンジンが同じセッションにないシナリオで役立ちます。 kill-on-barge-inプロンプトが再生されている場合、クライアントは、kill-on-barge-inを検出して実装できるように、RECOGNIZE要求を同時にアクティブにする必要がある場合があります。しかし同時に、クライアントは、プロンプトが終了するまで、認識エンジンが無入力タイマーを開始することを望んでいません。 RECOGNIZEリクエストのStart-Input-Timersヘッダーフィールドを使用すると、クライアントはタイマーをすぐに開始するかどうかを指定できます。そうでない場合、クライアントがSTART-INPUT-TIMERSメソッドを認識機能に送信するまで、認識機能リソースはタイマーを開始してはなりません（MUST NOT）。
This is an event from the recognizer resource to the client indicating that the recognition completed. The recognition result is sent in the body of the MRCPv2 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 server MUST maintain the recognizer context containing the results and the audio waveform input of that recognition until the next RECOGNIZE request is issued for that resource or the session terminates. If the server returns a URI to the audio waveform, it MUST do so in a Waveform-URI header field in the RECOGNITION-COMPLETE event. The client can use this URI to retrieve or playback the audio.
これは、認識リソースからクライアントへのイベントであり、認識が完了したことを示します。認識結果はMRCPv2メッセージの本文で送信されます。 request-stateフィールドは、これがそのrequest-idを持つ最後のイベントであり、そのrequest-idを持つ要求が完了したことを示すCOMPLETEである必要があります。サーバーは、そのリソースの次のRECOGNIZE要求が発行されるか、セッションが終了するまで、結果とその認識のオーディオ波形入力を含む認識機能コンテキストを維持する必要があります。サーバーがURIをオーディオ波形に返す場合は、RECOGNITION-COMPLETEイベントのWaveform-URIヘッダーフィールドで返す必要があります。クライアントはこのURIを使用してオーディオを取得または再生できます。
Note, if an enrollment session was active, the RECOGNITION-COMPLETE event can contain either recognition or enrollment results depending on what was spoken. The following example shows a complete exchange with a recognition result.
登録セッションがアクティブであった場合、RECOGNITION-COMPLETEイベントには、話された内容に応じて認識結果または登録結果が含まれる可能性があることに注意してください。次の例は、認識結果との完全な交換を示しています。
C->S: MRCP/2.0 ... RECOGNIZE 543257 Channel-Identifier:32AECB23433801@speechrecog Confidence-Threshold:0.9 Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... RECOGNIZE 543257 Channel-Identifier：32AECB23433801 @ speechrecog Confidence-Threshold：0.9 Content-Type：application / srgs + xml Content-ID：<request1@form-level.store> Content-Length ：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... START-OF-INPUT 543257 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... RECOGNITION-COMPLETE 543257 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Waveform-URI:<http://web.media.com/session123/audio.wav>; size=342456;duration=25435 Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... RECOGNITION-COMPLETE 543257 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Waveform-URI：<http://web.media.com/session123/audio.wav> ; size = 342456; duration = 25435 Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
If the result were instead an enrollment result, the final message from the server above could have been:
結果が登録結果ではなかった場合、上記のサーバーからの最終メッセージは次のようになります。
S->C: MRCP/2.0 ... RECOGNITION-COMPLETE 543257 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... RECOGNITION-COMPLETE 543257 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Content-Type：application / nlsml + xml Content-Length：...
<?xml version= "1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="Personal-Grammar-URI">
<enrollment-result>
<num-clashes> 2 </num-clashes>
<num-good-repetitions> 1 </num-good-repetitions>
<num-repetitions-still-needed>
1
</num-repetitions-still-needed>
<consistency-status> consistent </consistency-status>
<clash-phrase-ids>
<item> Jeff </item> <item> Andre </item>
</clash-phrase-ids>
<transcriptions>
<item> m ay b r ow k er </item>
<item> m ax r aa k ah </item>
</transcriptions>
<confusable-phrases>
<item>
<phrase> call </phrase>
<confusion-level> 10 </confusion-level>
</item>
</confusable-phrases>
</enrollment-result>
</result>
The START-PHRASE-ENROLLMENT method from the client to the server starts a new phrase enrollment session during which the client can call RECOGNIZE multiple times to enroll a new utterance in a grammar. An enrollment session consists of a set of calls to RECOGNIZE in which the caller speaks a phrase several times so the system can "learn" it. The phrase is then added to a personal grammar (speaker-trained grammar), so that the system can recognize it later.
クライアントからサーバーへのSTART-PHRASE-ENROLLMENTメソッドは、新しいフレーズ登録セッションを開始します。その間に、クライアントはRECOGNIZEを複数回呼び出して、新しい発話を文法に登録できます。登録セッションはRECOGNIZEへの一連の呼び出しで構成され、発呼者はフレーズを数回話して、システムがフレーズを「学習」できるようにします。次に、フレーズが個人の文法（スピーカーでトレーニングされた文法）に追加され、システムが後でそれを認識できるようになります。
Only one phrase enrollment session can be active at a time for a resource. The Personal-Grammar-URI identifies the grammar that is used during enrollment to store the personal list of phrases. Once RECOGNIZE is called, the result is returned in a RECOGNITION-COMPLETE event and will contain either an enrollment result OR a recognition result for a regular recognition.
リソースに対して一度にアクティブにできるフレーズ登録セッションは1つだけです。 Personal-Grammar-URIは、登録時にフレーズの個人用リストを保管するために使用される文法を識別します。 RECOGNIZEが呼び出されると、結果はRECOGNITION-COMPLETEイベントで返され、登録結果または通常の認識の認識結果が含まれます。
Calling END-PHRASE-ENROLLMENT ends the ongoing phrase enrollment session, which is typically done after a sequence of successful calls to RECOGNIZE. This method can be called to commit the new phrase to the personal grammar or to abort the phrase enrollment session.
END-PHRASE-ENROLLMENTを呼び出すと、進行中のフレーズ登録セッションが終了します。これは通常、RECOGNIZEへの一連の呼び出しが成功した後に行われます。このメソッドを呼び出して、新しいフレーズを個人の文法にコミットするか、フレーズ登録セッションを中止することができます。
The grammar to contain the new enrolled phrase, specified by Personal-Grammar-URI, is created if it does not exist. Also, the personal grammar MUST ONLY contain phrases added via a phrase enrollment session.
Personal-Grammar-URIで指定された新しい登録フレーズを含む文法は、存在しない場合に作成されます。また、個人の文法には、フレーズ登録セッションで追加されたフレーズのみを含める必要があります。
The Phrase-ID passed to this method is used to identify this phrase in the grammar and will be returned as the speech input when doing a RECOGNIZE on the grammar. The Phrase-NL similarly is returned in a RECOGNITION-COMPLETE event in the same manner as other Natural Language (NL) in a grammar. The tag-format of this NL is implementation specific.
このメソッドに渡されたフレーズIDは、文法でこのフレーズを識別するために使用され、文法で認識を行うときに音声入力として返されます。同様に、Phrase-NLは、文法内の他の自然言語（NL）と同じ方法でRECOGNITION-COMPLETEイベントで返されます。このNLのタグ形式は実装固有です。
If the client has specified Save-Best-Waveform as true, then the response after ending the phrase enrollment session MUST contain the location/URI of a recording of the best repetition of the learned phrase.
If the client has specified Save-Best-Waveform as true, then the response after ending the phrase enrollment session MUST contain the location/URI of a recording of the best repetition of the learned phrase.
C->S: MRCP/2.0 ... START-PHRASE-ENROLLMENT 543258
Channel-Identifier:32AECB23433801@speechrecog
Num-Min-Consistent-Pronunciations:2
Consistency-Threshold:30
Clash-Threshold:12
Personal-Grammar-URI:<personal grammar uri>
Phrase-Id:<phrase id>
Phrase-NL:<NL phrase>
Weight:1
Save-Best-Waveform:true
S->C: MRCP/2.0 ... 543258 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
The ENROLLMENT-ROLLBACK method discards the last live utterance from the RECOGNIZE operation. The client can invoke this method when the caller provides undesirable input such as non-speech noises, side-speech, commands, utterance from the RECOGNIZE grammar, etc. Note that this method does not provide a stack of rollback states. Executing ENROLLMENT-ROLLBACK twice in succession without an intervening recognition operation has no effect the second time.
ENROLLMENT-ROLLBACKメソッドは、RECOGNIZE操作からの最後のライブ発話を破棄します。呼び出し元が非音声ノイズ、副音声、コマンド、認識文法からの発声などの望ましくない入力を提供すると、クライアントはこのメソッドを呼び出すことができます。このメソッドはロールバック状態のスタックを提供しないことに注意してください。 ENROLLMENT-ROLLBACKを続けて2回実行しても、認識操作は行われず、2回目に影響はありません。
C->S: MRCP/2.0 ... ENROLLMENT-ROLLBACK 543261
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... 543261 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
The client MAY call the END-PHRASE-ENROLLMENT method ONLY during an active phrase enrollment session. It MUST NOT be called during an ongoing RECOGNIZE operation. To commit the new phrase in the grammar, the client MAY call this method once successive calls to RECOGNIZE have succeeded and Num-Repetitions-Still-Needed has been returned as 0 in the RECOGNITION-COMPLETE event. Alternatively, the client MAY abort the phrase enrollment session by calling this method with the Abort-Phrase-Enrollment header field.
クライアントは、アクティブなフレーズ登録セッション中にのみ、END-PHRASE-ENROLLMENTメソッドを呼び出すことができます。進行中のRECOGNIZE操作中に呼び出すことはできません。文法の新しいフレーズをコミットするには、クライアントは、RECOGNIZEへの連続した呼び出しが成功し、Num-Repetitions-Still-NeededがRECOGNITION-COMPLETEイベントで0として返されると、このメソッドを呼び出すことができます（MAY）。または、クライアントは、Abort-Phrase-Enrollmentヘッダーフィールドを指定してこのメソッドを呼び出すことにより、フレーズ登録セッションを中止してもよい（MAY）。
If the client has specified Save-Best-Waveform as "true" in the START-PHRASE-ENROLLMENT request, then the response MUST contain a Waveform-URI header whose value is the location/URI of a recording of the best repetition of the learned phrase.
クライアントがSTART-PHRASE-ENROLLMENTリクエストでSave-Best-Waveformを「true」に指定している場合、応答には、学習した最適な繰り返しの記録の場所/ URIである値を持つWaveform-URIヘッダーが含まれている必要があります。フレーズ。
C->S: MRCP/2.0 ... END-PHRASE-ENROLLMENT 543262
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... 543262 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
Waveform-URI:<http://mediaserver.com/recordings/file1324.wav>;
size=242453;duration=25432
The MODIFY-PHRASE method sent from the client to the server is used to change the phrase ID, NL phrase, and/or weight for a given phrase in a personal grammar.
クライアントからサーバーに送信されたMODIFY-PHRASEメソッドは、個人の文法で指定されたフレーズのフレーズID、NLフレーズ、および/または重みを変更するために使用されます。
If no fields are supplied, then calling this method has no effect.
フィールドが指定されていない場合、このメソッドを呼び出しても効果はありません。
C->S: MRCP/2.0 ... MODIFY-PHRASE 543265
Channel-Identifier:32AECB23433801@speechrecog
Personal-Grammar-URI:<personal grammar uri>
Phrase-Id:<phrase id>
New-Phrase-Id:<new phrase id>
Phrase-NL:<NL phrase>
Weight:1
S->C: MRCP/2.0 ... 543265 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
The DELETE-PHRASE method sent from the client to the server is used to delete a phase that is in a personal grammar and was added through voice enrollment or text enrollment. If the specified phrase does not exist, this method has no effect.
クライアントからサーバーに送信されるDELETE-PHRASEメソッドは、個人の文法に含まれ、音声登録またはテキスト登録によって追加されたフェーズを削除するために使用されます。指定されたフレーズが存在しない場合、このメソッドは効果がありません。
C->S: MRCP/2.0 ... DELETE-PHRASE 543266
Channel-Identifier:32AECB23433801@speechrecog
Personal-Grammar-URI:<personal grammar uri>
Phrase-Id:<phrase id>
S->C: MRCP/2.0 ... 543266 200 COMPLETE
Channel-Identifier:32AECB23433801@speechrecog
The INTERPRET method from the client to the server takes as input an Interpret-Text header field containing the text for which the semantic interpretation is desired, and returns, via the INTERPRETATION-COMPLETE event, an interpretation result that is very similar to the one returned from a RECOGNIZE method invocation. Only portions of the result relevant to acoustic matching are excluded from the result. The Interpret-Text header field MUST be included in the INTERPRET request.
クライアントからサーバーへのINTERPRETメソッドは、意味解釈が必要なテキストを含むInterpret-Textヘッダーフィールドを入力として受け取り、INTERPRETATION-COMPLETEイベントを介して、返されたものと非常に類似した解釈結果を返します。 RECOGNIZEメソッドの呼び出しから。音響マッチングに関連する結果の部分のみが結果から除外されます。 Interpret-Textヘッダーフィールドは、INTERPRET要求に含める必要があります。
Recognizer grammar data is treated in the same way as it is when issuing a RECOGNIZE method call.
Recognizer文法データは、RECOGNIZEメソッド呼び出しを発行するときと同じように扱われます。
If a RECOGNIZE, RECORD, or another INTERPRET operation is already in progress for the resource, the server MUST reject the request with a response having a status-code of 402 "Method not valid in this state", and a COMPLETE request state.
RECOGNIZE、RECORD、または別のINTERPRET操作がリソースに対してすでに進行中の場合、サーバーはステータスコード402「この状態では無効」の応答とCOMPLETE要求状態で要求を拒否する必要があります。
C->S: MRCP/2.0 ... INTERPRET 543266 Channel-Identifier:32AECB23433801@speechrecog Interpret-Text:may I speak to Andre Roy Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... INTERPRET 543266 Channel-Identifier：32AECB23433801 @ speechrecog Interpret-Text：Andre Roy Content-Type：application / srgs + xml Content-ID：<request1 @ form-level。ストア> Content-Length：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 ... 543266 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... INTERPRETATION-COMPLETE 543266 200 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... INTERPRETATION-COMPLETE 543266 200 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
This event from the recognizer resource to the client indicates that the INTERPRET operation is complete. The interpretation result is sent in the body of the MRCP message. The request state MUST be set to COMPLETE.
認識リソースからクライアントへのこのイベントは、INTERPRET操作が完了したことを示します。解釈結果はMRCPメッセージの本文で送信されます。リクエストの状態はCOMPLETEに設定する必要があります。
The Completion-Cause header field MUST be included in this event and MUST be set to an appropriate value from the list of cause codes.
Completion-Causeヘッダーフィールドはこのイベントに含める必要があり、原因コードのリストから適切な値に設定する必要があります。
C->S: MRCP/2.0 ... INTERPRET 543266 Channel-Identifier:32AECB23433801@speechrecog Interpret-Text:may I speak to Andre Roy Content-Type:application/srgs+xml Content-ID:<request1@form-level.store> Content-Length:...
C-> S：MRCP / 2.0 ... INTERPRET 543266 Channel-Identifier：32AECB23433801 @ speechrecog Interpret-Text：Andre Roy Content-Type：application / srgs + xml Content-ID：<request1 @ form-level。ストア> Content-Length：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C: MRCP/2.0 ... 543266 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
S->C: MRCP/2.0 ... INTERPRETATION-COMPLETE 543266 200 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... INTERPRETATION-COMPLETE 543266 200 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Digits received as DTMF tones are delivered to the recognition resource in the MRCPv2 server in the RTP stream according to RFC 4733 [RFC4733]. The Automatic Speech Recognizer (ASR) MUST support RFC 4733 to recognize digits, and it MAY support recognizing DTMF tones [Q.23] in the audio.
DTMFトーンとして受信された数字は、RFC 4733 [RFC4733]に従って、RTPストリームでMRCPv2サーバーの認識リソースに配信されます。自動音声認識（ASR）は、数字を認識するためにRFC 4733をサポートする必要があります。また、音声のDTMFトーン[Q.23]の認識をサポートする場合があります。
This resource captures received audio and video and stores it as content pointed to by a URI. The main usages of recorders are
このリソースは、受信したオーディオとビデオをキャプチャし、URIが指すコンテンツとして保存します。レコーダーの主な用途は
1. to capture speech audio that may be submitted for recognition at a later time, and
1. 後で認識のために送信される可能性のある音声をキャプチャするため、および
2. recording voice or video mails.
2. ボイスメールまたはビデオメールの録音。
Both these applications require functionality above and beyond those specified by protocols such as RTSP [RFC2326]. This includes audio endpointing (i.e., detecting speech or silence). The support for video is OPTIONAL and is mainly capturing video mails that may require the speech or audio processing mentioned above.
これらのアプリケーションはどちらも、RTSP [RFC2326]などのプロトコルで指定されている以上の機能を必要とします。これには、音声のエンドポイント設定（つまり、音声や沈黙の検出）が含まれます。ビデオのサポートはオプションであり、主に上記のスピーチまたはオーディオ処理を必要とするビデオメールをキャプチャします。
A recorder MUST provide endpointing capabilities for suppressing silence at the beginning and end of a recording, and it MAY also suppress silence in the middle of a recording. If such suppression is done, the recorder MUST maintain timing metadata to indicate the actual time stamps of the recorded media.
レコーダーは、録音の開始時と終了時の無音を抑制するためのエンドポイント機能を提供する必要があります。また、録音の途中での無音も抑制できます（MAY）。そのような抑制が行われる場合、レコーダーは記録されたメディアの実際のタイムスタンプを示すためにタイミングメタデータを維持しなければなりません。
See the discussion on the sensitivity of saved waveforms in Section 12.
セクション12の保存された波形の感度に関する説明を参照してください。
Idle Recording
State State
| |
|---------RECORD------->|
| |
|<------STOP------------|
| |
|<--RECORD-COMPLETE-----|
| |
| |--------|
| START-OF-INPUT |
| |------->|
| |
| |--------|
| START-INPUT-TIMERS |
| |------->|
| |
Recorder State Machine
レコーダーステートマシン
The recorder resource supports the following methods.
レコーダーリソースは、次のメソッドをサポートします。
recorder-method = "RECORD" / "STOP" / "START-INPUT-TIMERS"
Recorder-method = "RECORD" / "STOP" / "START-INPUT-TIMERS"
The recorder resource can generate the following events.
レコーダーリソースは、次のイベントを生成できます。
recorder-event = "START-OF-INPUT" / "RECORD-COMPLETE"
レコーダーイベント= "START-OF-INPUT" / "RECORD-COMPLETE"
Method invocations for the recorder resource can contain resource-specific header fields containing request options and information to augment the Method, Response, or Event message it is associated with.
レコーダーリソースのメソッド呼び出しには、関連付けられているメソッド、応答、またはイベントメッセージを拡張するための要求オプションと情報を含むリソース固有のヘッダーフィールドを含めることができます。
recorder-header = sensitivity-level
/ no-input-timeout
/ completion-cause
/ completion-reason
/ failed-uri
/ failed-uri-cause
/ record-uri
/ media-type
/ max-time
/ trim-length
/ final-silence
/ capture-on-speech
/ ver-buffer-utterance
/ start-input-timers
/ new-audio-channel
To filter out background noise and not mistake it for speech, the recorder can support a variable level of sound sensitivity. The Sensitivity-Level header field is a float value between 0.0 and 1.0 and allows the client to set the sensitivity level for the recorder. This header field MAY occur in RECORD, SET-PARAMS, or GET-PARAMS. A higher value for this header field means higher sensitivity. The default value for this header field is implementation specific.
バックグラウンドノイズを取り除き、それを音声と間違えないように、レコーダーはさまざまなレベルの音響感度をサポートできます。 Sensitivity-Levelヘッダーフィールドは0.0〜1.0の浮動小数点値で、クライアントがレコーダーの感度レベルを設定できるようにします。このヘッダーフィールドは、RECORD、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値が大きいほど、感度が高くなります。このヘッダーフィールドのデフォルト値は実装固有です。
sensitivity-level = "Sensitivity-Level" ":" FLOAT CRLF
感度レベル= "感度レベル" "：" FLOAT CRLF
When recording is started and there is no speech detected for a certain period of time, the recorder can send a RECORD-COMPLETE event to the client and terminate the record operation. The No-Input-Timeout header field can set this timeout value. The value is in milliseconds. This header field MAY occur in RECORD, SET-PARAMS, or GET-PARAMS. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value for this header field is implementation specific.
録音が開始され、一定時間音声が検出されない場合、レコーダーはRECORD-COMPLETEイベントをクライアントに送信し、録音操作を終了できます。 No-Input-Timeoutヘッダーフィールドは、このタイムアウト値を設定できます。値はミリ秒単位です。このヘッダーフィールドは、RECORD、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。このヘッダーフィールドのデフォルト値は実装固有です。
no-input-timeout = "No-Input-Timeout" ":" 1*19DIGIT CRLF
This header field MUST be part of a RECORD-COMPLETE event from the recorder resource to the client. This indicates the reason behind the RECORD method completion. This header field MUST be sent in the RECORD responses if they return with a failure status and a COMPLETE state. In the ABNF below, the 'cause-code' contains a numerical value selected from the Cause-Code column of the following table. The 'cause-name' contains the corresponding token selected from the Cause-Name column.
このヘッダーフィールドは、レコーダーリソースからクライアントへのRECORD-COMPLETEイベントの一部である必要があります。これは、RECORDメソッドが完了した理由を示しています。このヘッダーフィールドは、障害ステータスとCOMPLETE状態で戻る場合、RECORD応答で送信する必要があります。以下のABNFでは、「原因コード」には、次の表の「原因コード」列から選択された数値が含まれています。 「原因名」には、原因名列から選択された対応するトークンが含まれています。
completion-cause = "Completion-Cause" ":" cause-code SP
cause-name CRLF
cause-code = 3DIGIT
cause-name = *VCHAR
+------------+-----------------------+------------------------------+
| Cause-Code | Cause-Name | Description |
+------------+-----------------------+------------------------------+
| 000 | success-silence | RECORD completed with a |
| | | silence at the end. |
| 001 | success-maxtime | RECORD completed after |
| | | reaching maximum recording |
| | | time specified in record |
| | | method. |
| 002 | no-input-timeout | RECORD failed due to no |
| | | input. |
| 003 | uri-failure | Failure accessing the record |
| | | URI. |
| 004 | error | RECORD request terminated |
| | | prematurely due to a |
| | | recorder error. |
+------------+-----------------------+------------------------------+
This header field MAY be present in a RECORD-COMPLETE event coming from the recorder resource to the client. It contains the reason text behind the RECORD request completion. This header field communicates text describing the reason for the failure.
このヘッダーフィールドは、レコーダーリソースからクライアントに送信されるRECORD-COMPLETEイベントに存在する場合があります。これには、RECORD要求の完了の背後にある理由テキストが含まれています。このヘッダーフィールドは、失敗の理由を説明するテキストを伝えます。
The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients MUST NOT interpret the completion reason text.
完了理由のテキストは、クライアントがログで使用するため、およびデバッグと計測の目的で提供されます。クライアントは完了理由テキストを解釈してはなりません。
completion-reason = "Completion-Reason" ":" quoted-string CRLF
completion-reason = "Completion-Reason" "："引用文字列CRLF
When a recorder method needs to post the audio to a URI and access to the URI fails, the server MUST provide the failed URI in this header field in the method response.
レコーダーメソッドがオーディオをURIにポストする必要があり、URIへのアクセスが失敗した場合、サーバーはメソッド応答のこのヘッダーフィールドに失敗したURIを提供する必要があります。
failed-uri = "Failed-URI" ":" absoluteURI CRLF
failed-uri = "Failed-URI" "：" absoluteURI CRLF
When a recorder method needs to post the audio to a URI and access to the URI fails, the server MAY provide the URI-specific or protocol-specific response code through this header field in the method response. The value encoding is UTF-8 (RFC 3629 [RFC3629]) to accommodate any access protocol -- some access protocols might have a response string instead of a numeric response code.
レコーダーメソッドがオーディオをURIにポストする必要があり、URIへのアクセスが失敗した場合、サーバーはメソッド応答のこのヘッダーフィールドを介してURI固有またはプロトコル固有の応答コードを提供できます（MAY）。値のエンコードはUTF-8（RFC 3629 [RFC3629]）であり、あらゆるアクセスプロトコルに対応します。一部のアクセスプロトコルには、数値応答コードの代わりに応答文字列が含まれる場合があります。
failed-uri-cause = "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
failed-uri-cause = "Failed-URI-Cause" "：" 1 * UTFCHAR CRLF
When a recorder method contains this header field, the server MUST capture the audio and store it. If the header field is present but specified with no value, the server MUST store the content locally and generate a URI that points to it. This URI is then returned in either the STOP response or the RECORD-COMPLETE event. If the header field in the RECORD method specifies a URI, the server MUST attempt to capture and store the audio at that location. If this header field is not specified in the RECORD request, the server MUST capture the audio, MUST encode it, and MUST send it in the STOP response or the RECORD-COMPLETE event as a message body. In this case, the response carrying the audio content MUST include a Content ID (cid) [RFC2392] value in this header pointing to the Content-ID in the message body.
レコーダーメソッドにこのヘッダーフィールドが含まれている場合、サーバーは音声をキャプチャして保存する必要があります。ヘッダーフィールドは存在するが値が指定されていない場合、サーバーはコンテンツをローカルに保存し、それを指すURIを生成する必要があります。このURIは、STOP応答またはRECORD-COMPLETEイベントで返されます。 RECORDメソッドのヘッダーフィールドでURIが指定されている場合、サーバーはその場所でオーディオをキャプチャして保存する必要があります。このヘッダーフィールドがRECORDリクエストで指定されていない場合、サーバーは音声をキャプチャし、エンコードし、STOPレスポンスまたはRECORD-COMPLETEイベントでメッセージ本文として送信する必要があります。この場合、オーディオコンテンツを運ぶ応答は、メッセージ本文のContent-IDを指すこのヘッダーにContent ID（cid）[RFC2392]値を含める必要があります。
The server MUST also return the size in octets and the duration in milliseconds of the recorded audio waveform as parameters associated with the header field.
サーバーは、ヘッダーフィールドに関連付けられたパラメーターとして、記録されたオーディオ波形のオクテット単位のサイズとミリ秒単位の期間も返す必要があります。
Implementations MUST support 'http' [RFC2616], 'https' [RFC2818], 'file' [RFC3986], and 'cid' [RFC2392] schemes in the URI. Note that implementations already exist that support other schemes.
実装は、URIで「http」[RFC2616]、「https」[RFC2818]、「ファイル」[RFC3986]、および「cid」[RFC2392]スキームをサポートする必要があります。他のスキームをサポートする実装がすでに存在していることに注意してください。
record-uri = "Record-URI" ":" ["<" uri ">"
";" "size" "=" 1*19DIGIT
";" "duration" "=" 1*19DIGIT] CRLF
A RECORD method MUST contain this header field, which specifies to the server the media type of the captured audio or video.
RECORDメソッドには、このヘッダーフィールドを含める必要があります。このヘッダーフィールドは、キャプチャしたオーディオまたはビデオのメディアタイプをサーバーに指定します。
media-type = "Media-Type" ":" media-type-value CRLF
media-type = "Media-Type" "：" media-type-value CRLF
When recording is started, this specifies the maximum length of the recording in milliseconds, calculated from the time the actual capture and store begins and is not necessarily the time the RECORD method is received. It specifies the duration before silence suppression, if any, has been applied by the recorder resource. After this time, the recording stops and the server MUST return a RECORD-COMPLETE event to the client having a request-state of COMPLETE. This header field MAY occur in RECORD, SET-PARAMS, or GET-PARAMS. The value for this header field ranges from 0 to an implementation-specific maximum value. A value of 0 means infinity, and hence the recording continues until one or more of the other stop conditions are met. The default value for this header field is 0.
記録が開始されるとき、これはミリ秒単位で記録の最大長を指定します。実際のキャプチャとストアが開始した時刻から計算され、必ずしもRECORDメソッドが受信された時刻とは限りません。無音抑制がある場合は、それがレコーダーリソースによって適用されるまでの期間を指定します。この時間の後、記録は停止し、サーバーはリクエスト状態がCOMPLETEのクライアントにRECORD-COMPLETEイベントを返さなければなりません（MUST）。このヘッダーフィールドは、RECORD、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。値0は無限を意味するため、他の停止条件が1つ以上満たされるまで記録が続行されます。このヘッダーフィールドのデフォルト値は0です。
max-time = "Max-Time" ":" 1*19DIGIT CRLF
This header field MAY be sent on a STOP method and specifies the length of audio to be trimmed from the end of the recording after the stop. The length is interpreted to be in milliseconds. The default value for this header field is 0.
This header field MAY be sent on a STOP method and specifies the length of audio to be trimmed from the end of the recording after the stop. The length is interpreted to be in milliseconds. The default value for this header field is 0.
trim-length = "Trim-Length" ":" 1*19DIGIT CRLF
When the recorder is started and the actual capture begins, this header field specifies the length of silence in the audio that is to be interpreted as the end of the recording. This header field MAY occur in RECORD, SET-PARAMS, or GET-PARAMS. The value for this header field ranges from 0 to an implementation-specific maximum value and is interpreted to be in milliseconds. A value of 0 means infinity, and hence the recording will continue until one of the other stop conditions are met. The default value for this header field is implementation specific.
レコーダーが開始され、実際のキャプチャが開始されると、このヘッダーフィールドは、録音の終了として解釈されるオーディオの無音の長さを指定します。このヘッダーフィールドは、RECORD、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値の範囲は0から実装固有の最大値であり、ミリ秒単位であると解釈されます。値0は無限を意味するため、他の停止条件のいずれかが満たされるまで記録が続行されます。このヘッダーフィールドのデフォルト値は実装固有です。
final-silence = "Final-Silence" ":" 1*19DIGIT CRLF
If "false", the recorder MUST start capturing immediately when started. If "true", the recorder MUST wait for the endpointing functionality to detect speech before it starts capturing. This header field MAY occur in the RECORD, SET-PARAMS, or GET-PARAMS. The value for this header field is a Boolean. The default value for this header field is "false".
「false」の場合、レコーダーは開始時にすぐにキャプチャを開始する必要があります。 「true」の場合、レコーダーは、エンドポイント機能が音声を検出するのを待ってから、キャプチャを開始する必要があります。このヘッダーフィールドは、RECORD、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値はブール値です。このヘッダーフィールドのデフォルト値は「false」です。
capture-on-speech = "Capture-On-Speech " ":" BOOLEAN CRLF
capture-on-speech = "Capture-On-Speech" "：" BOOLEAN CRLF
This header field is the same as the one described for the verifier resource (see Section 11.4.14). This tells the server to buffer the utterance associated with this recording request into the verification buffer. Sending this header field is permitted only if the verification buffer is for the session. This buffer is shared across resources within a session. It gets instantiated when a verifier resource is added to this session and is released when the verifier resource is released from the session.
このヘッダーフィールドは、ベリファイアリソースについて説明したものと同じです（セクション11.4.14を参照）。これは、この記録要求に関連する発話を検証バッファーにバッファーするようサーバーに指示します。このヘッダーフィールドの送信は、検証バッファがセッション用である場合にのみ許可されます。このバッファーは、セッション内のリソース間で共有されます。ベリファイアリソースがこのセッションに追加されるとインスタンス化され、ベリファイアリソースがセッションから解放されると解放されます。
This header field MAY be sent as part of the RECORD request. A value of "false" tells the recorder resource to start the operation, but not to start the no-input timer until the client sends a START-INPUT-TIMERS request to the recorder resource. This is useful in the scenario when the recorder and synthesizer resources are not part of the same session. When a kill-on-barge-in prompt is being played, the client may want the RECORD request to be simultaneously active so that it can detect and implement kill-on-barge-in (see Section 8.4.2). But at the same time, the client doesn't want the recorder resource to start the no-input timers until the prompt is finished. The default value is "true".
このヘッダーフィールドは、RECORDリクエストの一部として送信される場合があります。 「false」の値は、レコーダーリソースに操作を開始するよう指示しますが、クライアントがSTART-INPUT-TIMERS要求をレコーダーリソースに送信するまで、無入力タイマーを開始しません。これは、レコーダーとシンセサイザーのリソースが同じセッションの一部ではない場合に役立ちます。 kill-on-barge-inプロンプトが再生されているとき、クライアントは、RECORD要求を同時にアクティブにして、kill-on-barge-inを検出および実装できるようにする場合があります（セクション8.4.2を参照）。しかし、同時に、クライアントは、プロンプトが終了するまで、レコーダーリソースが無入力タイマーを開始することを望みません。デフォルト値は「true」です。
start-input-timers = "Start-Input-Timers" ":" BOOLEAN CRLF
start-input-timers = "Start-Input-Timers" "：" BOOLEAN CRLF
This header field is the same as the one described for the recognizer resource (see Section 9.4.23).
このヘッダーフィールドは、認識リソースについて説明したものと同じです（セクション9.4.23を参照）。
If the RECORD request did not have a Record-URI header field, the STOP response or the RECORD-COMPLETE event MUST contain a message body carrying the captured audio. In this case, the message carrying the audio content has a Record-URI header field with a Content ID value pointing to the message body entity that contains the recorded audio. See Section 10.4.7 for details.
RECORD要求にRecord-URIヘッダーフィールドがなかった場合、STOP応答またはRECORD-COMPLETEイベントには、キャプチャされたオーディオを運ぶメッセージ本文が含まれている必要があります。この場合、オーディオコンテンツを運ぶメッセージには、録音されたオーディオを含むメッセージ本文エンティティを指すコンテンツID値を持つRecord-URIヘッダーフィールドがあります。詳細については、セクション10.4.7を参照してください。
The RECORD request places the recorder resource in the recording state. Depending on the header fields specified in the RECORD method, the resource may start recording the audio immediately or wait for the endpointing functionality to detect speech in the audio. The audio is then made available to the client either in the message body or as specified by Record-URI.
RECORD要求は、レコーダーリソースを記録状態にします。 RECORDメソッドで指定されたヘッダーフィールドに応じて、リソースはすぐにオーディオの録音を開始するか、エンドポイント機能がオーディオの音声を検出するのを待ちます。オーディオは、メッセージ本文で、またはRecord-URIで指定されたとおりに、クライアントで使用できるようになります。
The server MUST support the 'https' URI scheme and MAY support other schemes. Note that, due to the sensitive nature of voice recordings, any protocols used for dereferencing SHOULD employ integrity and confidentiality, unless other means, such as use of a controlled environment (see Section 4.2), are employed.
サーバーは「https」URIスキームをサポートする必要があり、他のスキームをサポートする場合があります。音声録音は機密性が高いため、制御された環境（4.2項を参照）の使用などの他の手段を使用しない限り、逆参照に使用されるプロトコルは整合性と機密性を使用する必要があります。
If a RECORD operation is already in progress, invoking this method causes the server to issue a response having a status-code of 402 "Method not valid in this state" and a request-state of COMPLETE.
RECORD操作がすでに進行中の場合、このメソッドを呼び出すと、サーバーはステータスコード402「この状態ではメソッドが無効」と要求状態がCOMPLETEの応答を発行します。
If the Record-URI is not valid, a status-code of 404 "Illegal Value for Header Field" is returned in the response. If it is impossible for the server to create the requested stored content, a status-code of 407 "Method or Operation Failed" is returned.
Record-URIが有効でない場合、ステータスコード404「ヘッダーフィールドの無効な値」が応答で返されます。サーバーが要求された保存済みコンテンツを作成できない場合は、ステータスコード407「メソッドまたは操作が失敗しました」が返されます。
If the type specified in the Media-Type header field is not supported, the server MUST respond with a status-code of 409 "Unsupported Header Field Value" with the Media-Type header field in its response.
Media-Typeヘッダーフィールドで指定されたタイプがサポートされていない場合、サーバーは応答のMedia-Typeヘッダーフィールドで409 "Unsupported Header Field Value"のステータスコードで応答する必要があります。
When the recording operation is initiated, the response indicates an IN-PROGRESS request state. The server MAY generate a subsequent START-OF-INPUT event when speech is detected. Upon completion of the recording operation, the server generates a RECORD-COMPLETE event.
When the recording operation is initiated, the response indicates an IN-PROGRESS request state. The server MAY generate a subsequent START-OF-INPUT event when speech is detected. Upon completion of the recording operation, the server generates a RECORD-COMPLETE event.
C->S: MRCP/2.0 ... RECORD 543257
Channel-Identifier:32AECB23433802@recorder
Record-URI:<file://mediaserver/recordings/myfile.wav>
Media-Type:audio/wav
Capture-On-Speech:true
Final-Silence:300
Max-Time:6000
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@recorder
S->C: MRCP/2.0 ... START-OF-INPUT 543257 IN-PROGRESS
Channel-Identifier:32AECB23433802@recorder
S->C: MRCP/2.0 ... RECORD-COMPLETE 543257 COMPLETE
Channel-Identifier:32AECB23433802@recorder
Completion-Cause:000 success-silence
Record-URI:<file://mediaserver/recordings/myfile.wav>;
size=242552;duration=25645
RECORD Example
RECORDの例
The STOP method moves the recorder from the recording state back to the idle state. If a RECORD request is active and the STOP request successfully terminates it, then the STOP response MUST contain an Active-Request-Id-List header field containing the RECORD request-id that was terminated. In this case, no RECORD-COMPLETE event is sent for the terminated request. If there was no recording active, then the response MUST NOT contain an Active-Request-Id-List header field. If the recording was a success, the STOP response MUST contain a Record-URI header field pointing to the recorded audio content or to a typed entity in the body of the STOP response containing the recorded audio. The STOP method MAY have a Trim-Length header field, in which case the specified length of audio is trimmed from the end of the recording after the stop. In any case, the response MUST contain a status-code of 200 "Success".
STOPメソッドは、レコーダーを記録状態からアイドル状態に戻します。 RECORD要求がアクティブで、STOP要求が正常に終了した場合、STOP応答には、終了したRECORD要求IDを含むActive-Request-Id-Listヘッダーフィールドが含まれている必要があります。この場合、終了したリクエストに対してRECORD-COMPLETEイベントは送信されません。アクティブな記録がなかった場合、応答にはActive-Request-Id-Listヘッダーフィールドを含めてはなりません（MUST NOT）。録音が成功した場合、STOP応答には、録音された音声コンテンツまたは録音された音声を含むSTOP応答の本文の型付きエンティティを指すRecord-URIヘッダーフィールドが含まれている必要があります。 STOPメソッドにはTrim-Lengthヘッダーフィールドが含まれる場合があります。その場合、指定された長さのオーディオが、停止後の録音の最後からトリミングされます。いずれの場合も、応答には200 "成功"のステータスコードが含まれている必要があります。
C->S: MRCP/2.0 ... RECORD 543257
Channel-Identifier:32AECB23433802@recorder
Record-URI:<file://mediaserver/recordings/myfile.wav>
Capture-On-Speech:true
Final-Silence:300
Max-Time:6000
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@recorder
S->C: MRCP/2.0 ... START-OF-INPUT 543257 IN-PROGRESS
Channel-Identifier:32AECB23433802@recorder
C->S: MRCP/2.0 ... STOP 543257
Channel-Identifier:32AECB23433802@recorder
Trim-Length:200
S->C: MRCP/2.0 ... 543257 200 COMPLETE
Channel-Identifier:32AECB23433802@recorder
Record-URI:<file://mediaserver/recordings/myfile.wav>;
size=324253;duration=24561
Active-Request-Id-List:543257
STOP Example
STOP Example
If the recording completes due to no input, silence after speech, or reaching the max-time, the server MUST generate the RECORD-COMPLETE event to the client with a request-state of COMPLETE. If the recording was a success, the RECORD-COMPLETE event contains a Record-URI header field pointing to the recorded audio file on the server or to a typed entity in the message body containing the recorded audio.
入力がないため、発話後の無音時、または最大時間に達したために録音が完了した場合、サーバーは、リクエスト状態がCOMPLETEのRECORD-COMPLETEイベントをクライアントに生成する必要があります。録音が成功した場合、RECORD-COMPLETEイベントには、サーバー上の録音されたオーディオファイルまたは録音されたオーディオを含むメッセージ本文の型付きエンティティを指すRecord-URIヘッダーフィールドが含まれます。
C->S: MRCP/2.0 ... RECORD 543257
Channel-Identifier:32AECB23433802@recorder
Record-URI:<file://mediaserver/recordings/myfile.wav>
Capture-On-Speech:true
Final-Silence:300
Max-Time:6000
S->C: MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433802@recorder
S->C: MRCP/2.0 ... START-OF-INPUT 543257 IN-PROGRESS
Channel-Identifier:32AECB23433802@recorder
S->C: MRCP/2.0 ... RECORD-COMPLETE 543257 COMPLETE
Channel-Identifier:32AECB23433802@recorder
Completion-Cause:000 success
Record-URI:<file://mediaserver/recordings/myfile.wav>;
size=325325;duration=24652
RECORD-COMPLETE Example
RECORD-COMPLETEの例
This request is sent from the client to the recorder resource when it discovers that a kill-on-barge-in prompt has finished playing (see Section 8.4.2). This is useful in the scenario when the recorder and synthesizer resources are not in the same MRCPv2 session. When a kill-on-barge-in prompt is being played, the client wants the RECORD request to be simultaneously active so that it can detect and implement kill-on-barge-in. But at the same time, the client doesn't want the recorder resource to start the no-input timers until the prompt is finished. The Start-Input-Timers header field in the RECORD request allows the client to say if the timers should be started or not. In the above case, the recorder resource does not start the timers until the client sends a START-INPUT-TIMERS method to the recorder.
このリクエストは、kill-on-barge-inプロンプトの再生が終了したことを検出すると、クライアントからレコーダーリソースに送信されます（セクション8.4.2を参照）。これは、レコーダーとシンセサイザーのリソースが同じMRCPv2セッションにないシナリオで役立ちます。 kill-on-barge-inプロンプトが再生されている場合、クライアントは、RECORD要求を同時にアクティブにして、kill-on-barge-inを検出して実装できるようにします。しかし、同時に、クライアントは、プロンプトが終了するまで、レコーダーリソースが無入力タイマーを開始することを望みません。 RECORDリクエストのStart-Input-Timersヘッダーフィールドにより、クライアントはタイマーを開始する必要があるかどうかを通知できます。上記の場合、クライアントがSTART-INPUT-TIMERSメソッドをレコーダーに送信するまで、レコーダーリソースはタイマーを開始しません。
The START-OF-INPUT event is returned from the server to the client once the server has detected speech. This event is always returned by the recorder resource when speech has been detected. The recorder resource also MUST send a Proxy-Sync-Id header field with a unique value for this event.
The START-OF-INPUT event is returned from the server to the client once the server has detected speech. This event is always returned by the recorder resource when speech has been detected. The recorder resource also MUST send a Proxy-Sync-Id header field with a unique value for this event.
S->C: MRCP/2.0 ... START-OF-INPUT 543259 IN-PROGRESS
Channel-Identifier:32AECB23433801@recorder
Proxy-Sync-Id:987654321
This section describes the methods, responses and events employed by MRCPv2 for doing speaker verification/identification.
このセクションでは、話者の確認/識別を行うためにMRCPv2で使用される方法、応答、およびイベントについて説明します。
Speaker verification is a voice authentication methodology that can be used to identify the speaker in order to grant the user access to sensitive information and transactions. Because speech is a biometric, a number of essential security considerations related to biometric authentication technologies apply to its implementation and usage. Implementers should carefully read Section 12 in this document and the corresponding section of the SPEECHSC requirements [RFC4313]. Implementers and deployers of this technology are strongly encouraged to check the state of the art for any new risks and solutions that might have been developed.
話者認証は、機密情報やトランザクションへのアクセスをユーザーに許可するために話者を識別するために使用できる音声認証方法です。音声は生体認証であるため、生体認証技術に関連するセキュリティに関する重要な考慮事項が、その実装と使用に適用されます。実装者は、このドキュメントのセクション12とSPEECHSC要件の対応するセクション[RFC4313]を注意深く読む必要があります。このテクノロジーの実装者と配備者は、開発された可能性のある新しいリスクとソリューションについて、最新技術をチェックすることを強くお勧めします。
In speaker verification, a recorded utterance is compared to a previously stored voiceprint, which is in turn associated with a claimed identity for that user. Verification typically consists of two phases: a designation phase to establish the claimed identity of the caller and an execution phase in which a voiceprint is either created (training) or used to authenticate the claimed identity (verification).
話者の確認では、録音された発話が以前に保存された声紋と比較され、声紋はそのユーザーの主張されたIDに関連付けられます。検証は通常、2つのフェーズで構成されます。発信者の要求されたIDを確立する指定フェーズと、声紋が作成（トレーニング）または要求されたIDの認証（検証）に使用される実行フェーズです。
Speaker identification is the process of associating an unknown speaker with a member in a population. It does not employ a claim of identity. When an individual claims to belong to a group (e.g., one of the owners of a joint bank account) a group authentication is performed. This is generally implemented as a kind of verification involving comparison with more than one voice model. It is sometimes called 'multi-verification'. If the individual speaker can be identified from the group, this may be useful for applications where multiple users share the same access privileges to some data or application. Speaker identification and group authentication are also done in two phases, a designation phase and an execution phase. Note that, from a functionality standpoint, identification can be thought of as a special case of group authentication (if the individual is identified) where the group is the entire population, although the implementation of speaker identification may be different from the way group authentication is performed. To accommodate single-voiceprint verification, verification against multiple voiceprints, group authentication, and identification, this specification provides a single set of methods that can take a list of identifiers, called "voiceprint identifiers", and return a list of identifiers, with a score for each that represents how well the input speech matched each identifier. The input and output lists of identifiers do not have to match, allowing a vendor-specific group identifier to be used as input to indicate that identification is to be performed. In this specification, the terms "identification" and "multi-verification" are used to indicate that the input represents a group (potentially the entire population) and that results for multiple voiceprints may be returned.
話者識別は、未知の話者を母集団のメンバーに関連付けるプロセスです。それはアイデンティティの主張を採用していません。個人がグループ（共同銀行口座の所有者の1人など）に属していると主張する場合、グループ認証が実行されます。これは通常、複数の音声モデルとの比較を含む一種の検証として実装されます。 「マルチ検証」と呼ばれることもあります。グループから個々の話者を識別できる場合、これは、複数のユーザーが一部のデータまたはアプリケーションへの同じアクセス権限を共有するアプリケーションに役立つことがあります。話者の識別とグループ認証も、指定フェーズと実行フェーズの2つのフェーズで行われます。話者識別の実装はグループ認証の方法とは異なる場合がありますが、機能の観点から、識別はグループ認証の特別なケースと見なすことができます（個人が識別された場合）。実行されました。単一声紋検証、複数声紋に対する検証、グループ認証、および識別に対応するために、この仕様は、「声紋識別子」と呼ばれる識別子のリストを取得し、スコア付きの識別子のリストを返すことができる単一のメソッドセットを提供しますそれぞれ、入力音声が各識別子にどの程度一致したかを表します。識別子の入力リストと出力リストは一致する必要がないため、ベンダー固有のグループ識別子を入力として使用して、識別が実行されることを示すことができます。この仕様では、「識別」および「マルチ検証」という用語は、入力がグループ（潜在的には母集団全体）を表し、複数の声紋の結果が返されることを示すために使用されます。
It is possible for a verifier resource to share the same session with a recognizer resource or to operate independently. In order to share the same session, the verifier and recognizer resources MUST be allocated from within the same SIP dialog. Otherwise, an independent verifier resource, running on the same physical server or a separate one, will be set up. Note that, in addition to allowing both resources to be allocated in the same INVITE, it is possible to allocate one initially and the other later via a re-INVITE.
検証リソースが認識リソースと同じセッションを共有したり、独立して動作したりすることが可能です。同じセッションを共有するために、ベリファイアとレコグナイザのリソースは、同じSIPダイアログ内から割り当てられる必要があります。それ以外の場合は、同じ物理サーバーまたは別の物理サーバーで実行される独立した検証リソースがセットアップされます。両方のリソースを同じINVITEに割り当てることを許可することに加えて、最初に一方を割り当て、もう一方をre-INVITEを介して後で割り当てることができることに注意してください。
Some of the speaker verification methods, described below, apply only to a specific mode of operation.
以下で説明する話者確認方法の一部は、特定の動作モードにのみ適用されます。
The verifier resource has a verification buffer associated with it (see Section 11.4.14). This allows the storage of speech utterances for the purposes of verification, identification, or training from the buffered speech. This buffer is owned by the verifier resource, but other input resources (such as the recognizer resource or recorder resource) may write to it. This allows the speech received as part of a recognition or recording operation to be later used for verification, identification, or training. Access to the buffer is limited to one operation at time. Hence, when the resource is doing read, write, or delete operations, such as a RECOGNIZE with ver-buffer-utterance turned on, another operation involving the buffer fails with a status-code of 402. The verification buffer can be cleared by a CLEAR-BUFFER request from the client and is freed when the verifier resource is deallocated or the session with the server terminates.
ベリファイアリソースには、検証バッファが関連付けられています（セクション11.4.14を参照）。これにより、バッファリングされた音声からの検証、識別、またはトレーニングを目的とした音声発話の保存が可能になります。このバッファーは検証リソースによって所有されますが、他の入力リソース（認識リソースまたはレコーダーリソースなど）が書き込む可能性があります。これにより、認識または録音操作の一部として受信した音声を、後で検証、識別、またはトレーニングに使用できます。バッファへのアクセスは、一度に1つの操作に制限されています。したがって、リソースが読み取り、書き込み、または削除操作（ver-buffer-utteranceがオンになっているRECOGNIZEなど）を実行している場合、バッファーに関連する別の操作はステータスコード402で失敗します。検証バッファーは、クライアントからのCLEAR-BUFFER要求。ベリファイアリソースが割り当て解除されるか、サーバーとのセッションが終了すると解放されます。
The verification buffer is different from collecting waveforms and processing them using either the real-time audio stream or stored audio, because this buffering mechanism does not simply accumulate speech to a buffer. The verification buffer MAY contain additional information gathered by the recognizer resource that serves to improve verification performance.
このバッファリングメカニズムは音声をバッファに蓄積するだけではないため、検証バッファは、波形を収集してリアルタイムオーディオストリームまたは保存されたオーディオを使用して波形を処理することとは異なります。検証バッファは、検証パフォーマンスを改善するために役立つ認識機能リソースによって収集された追加情報を含むことができます。
Speaker verification may operate in a training or a verification session. Starting one of these sessions does not change the state of the verifier resource, i.e., it remains idle. Once a verification or training session is started, then utterances are trained or verified by calling the VERIFY or VERIFY-FROM-BUFFER method. The state of the verifier resources goes from IDLE to VERIFYING state each time VERIFY or VERIFY-FROM-BUFFER is called.
話者認証は、トレーニングまたは認証セッションで実施できます。これらのセッションの1つを開始しても、検証リソースの状態は変わりません。つまり、アイドル状態のままです。検証またはトレーニングセッションが開始されると、VERIFYまたはVERIFY-FROM-BUFFERメソッドを呼び出して発話がトレーニングまたは検証されます。検証リソースの状態は、VERIFYまたはVERIFY-FROM-BUFFERが呼び出されるたびにIDLEからVERIFYING状態になります。
Idle Session Opened Verifying/Training
State State State
| | |
|--START-SESSION--->| |
| | |
| |----------| |
| | START-SESSION |
| |<---------| |
| | |
|<--END-SESSION-----| |
| | |
| |---------VERIFY--------->|
| | |
| |---VERIFY-FROM-BUFFER--->|
| | |
| |----------| |
| | VERIFY-ROLLBACK |
| |<---------| |
| | |
| | |--------|
| | GET-INTERMEDIATE-RESULT |
| | |------->|
| | |
| | |--------|
| | START-INPUT-TIMERS |
| | |------->|
| | |
| | |--------|
| | START-OF-INPUT |
| | |------->|
| | |
| |<-VERIFICATION-COMPLETE--|
| | |
| |<--------STOP------------|
| | |
| |----------| |
| | STOP |
| |<---------| |
| | |
|----------| | |
| STOP | |
|<---------| | |
| |----------| |
| | CLEAR-BUFFER |
| |<---------| |
| | |
|----------| | |
| CLEAR-BUFFER | |
|<---------| | |
| | |
| |----------| |
| | QUERY-VOICEPRINT |
| |<---------| |
| | |
|----------| | |
| QUERY-VOICEPRINT | |
|<---------| | |
| | |
| |----------| |
| | DELETE-VOICEPRINT |
| |<---------| |
| | |
|----------| | |
| DELETE-VOICEPRINT | |
|<---------| | |
Verifier Resource State Machine
ベリファイアリソースステートマシン
The verifier resource supports the following methods.
ベリファイアリソースは、次のメソッドをサポートします。
verifier-method = "START-SESSION"
/ "END-SESSION"
/ "QUERY-VOICEPRINT"
/ "DELETE-VOICEPRINT"
/ "VERIFY"
/ "VERIFY-FROM-BUFFER"
/ "VERIFY-ROLLBACK"
/ "STOP"
/ "CLEAR-BUFFER"
/ "START-INPUT-TIMERS"
/ "GET-INTERMEDIATE-RESULT"
These methods allow the client to control the mode and target of verification or identification operations within the context of a session. All the verification input operations that occur within a session can be used to create, update, or validate against the voiceprint specified during the session. At the beginning of each session, the verifier resource is reset to the state it had prior to any previous verification session.
これらのメソッドにより、クライアントはセッションのコンテキスト内で検証または識別操作のモードとターゲットを制御できます。セッション内で発生するすべての検証入力操作は、セッション中に指定された声紋に対して作成、更新、または検証するために使用できます。各セッションの開始時に、検証リソースは、以前の検証セッションの前の状態にリセットされます。
Verification/identification operations can be executed against live or buffered audio. The verifier resource provides methods for collecting and evaluating live audio data, and methods for controlling the verifier resource and adjusting its configured behavior.
検証/識別操作は、ライブまたはバッファリングされたオーディオに対して実行できます。ベリファイアリソースは、ライブオーディオデータを収集および評価するためのメソッドと、ベリファイアリソースを制御し、その構成済み動作を調整するためのメソッドを提供します。
There are no dedicated methods for collecting buffered audio data. This is accomplished by calling VERIFY, RECOGNIZE, or RECORD as appropriate for the resource, with the header field Ver-Buffer-Utterance. Then, when the following method is called, verification is performed using the set of buffered audio.
バッファリングされたオーディオデータを収集するための専用の方法はありません。これは、ヘッダーフィールドのVer-Buffer-Utteranceを使用して、リソースに応じてVERIFY、RECOGNIZE、またはRECORDを呼び出すことによって行われます。次に、次のメソッドが呼び出されると、バッファリングされたオーディオのセットを使用して検証が実行されます。
1. VERIFY-FROM-BUFFER
1. バッファからの検証
The following methods are used for verification of live audio utterances:
次のメソッドは、ライブ音声発声の検証に使用されます。
1. VERIFY
1. 確認
2. START-INPUT-TIMERS
2. スタート入力タイマー
The following methods are used for configuring the verifier resource and for establishing resource states:
ベリファイアリソースの構成とリソースの状態の確立には、次のメソッドが使用されます。
1. START-SESSION
1. スタートセッション
2. END-SESSION
2. END-SESSION
3. QUERY-VOICEPRINT
3. QUERY-VOICEPRINT
4. DELETE-VOICEPRINT
4. 音声認識の削除
5. VERIFY-ROLLBACK
5. 検証ロールバック
6. STOP
6. やめる
7. CLEAR-BUFFER
7. クリアバッファー
The following method allows the polling of a verification in progress for intermediate results.
次の方法では、中間結果の進行中の検証をポーリングできます。
1. GET-INTERMEDIATE-RESULT
1. GET-INTERMEDIATE-RESULT
The verifier resource generates the following events.
検証リソースは、次のイベントを生成します。
verifier-event = "VERIFICATION-COMPLETE" / "START-OF-INPUT"
verifier-event = "VERIFICATION-COMPLETE" / "START-OF-INPUT"
A verifier resource message can contain header fields containing request options and information to augment the Request, Response, or Event message it is associated with.
ベリファイアリソースメッセージには、リクエストオプションと、それが関連付けられているリクエスト、レスポンス、またはイベントメッセージを拡張するための情報を含むヘッダーフィールドを含めることができます。
verification-header = repository-uri
/ voiceprint-identifier
/ verification-mode
/ adapt-model
/ abort-model
/ min-verification-score
/ num-min-verification-phrases
/ num-max-verification-phrases
/ no-input-timeout
/ save-waveform
/ media-type
/ waveform-uri
/ voiceprint-exists
/ ver-buffer-utterance
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ speech-complete-timeout
/ new-audio-channel
/ abort-verification
/ start-input-timers
This header field specifies the voiceprint repository to be used or referenced during speaker verification or identification operations. This header field is required in the START-SESSION, QUERY-VOICEPRINT, and DELETE-VOICEPRINT methods.
このヘッダーフィールドは、話者の確認または識別操作中に使用または参照される声紋リポジトリを指定します。このヘッダーフィールドは、START-SESSION、QUERY-VOICEPRINT、およびDELETE-VOICEPRINTメソッドで必須です。
repository-uri = "Repository-URI" ":" uri CRLF
れぽしとｒｙーうり ＝ ”れぽしとｒｙーうり” ”：” うり ＣＲＬＦ
This header field specifies the claimed identity for verification applications. The claimed identity MAY be used to specify an existing voiceprint or to establish a new voiceprint. This header field MUST be present in the QUERY-VOICEPRINT and DELETE-VOICEPRINT methods. The Voiceprint-Identifier MUST be present in the START-SESSION method for verification operations. For identification or multi-verification operations, this header field MAY contain a list of voiceprint identifiers separated by semicolons. For identification operations, the client MAY also specify a voiceprint group identifier instead of a list of voiceprint identifiers.
このヘッダーフィールドは、検証アプリケーションの申請IDを指定します。主張されたアイデンティティは、既存の声紋を指定するため、または新しい声紋を確立するために使用される場合があります。このヘッダーフィールドは、QUERY-VOICEPRINTおよびDELETE-VOICEPRINTメソッドに存在する必要があります。 Voiceprint-Identifierは、検証操作のためにSTART-SESSIONメソッドに存在している必要があります。識別またはマルチ検証操作の場合、このヘッダーフィールドには、セミコロンで区切られた声紋識別子のリストが含まれる場合があります。識別操作のために、クライアントは声紋識別子のリストの代わりに声紋グループ識別子も指定してもよい（MAY）。
voiceprint-identifier = "Voiceprint-Identifier" ":"
vid *[";" vid] CRLF
vid = 1*VCHAR ["." 1*VCHAR]
This header field specifies the mode of the verifier resource and is set by the START-SESSION method. Acceptable values indicate whether the verification session will train a voiceprint ("train") or verify/ identify using an existing voiceprint ("verify").
このヘッダーフィールドは、検証リソースのモードを指定し、START-SESSIONメソッドによって設定されます。許容値は、検証セッションが声紋をトレーニングする（「トレーニング」）か、既存の声紋を使用して検証/識別する（「検証」）かを示します。
Training and verification sessions both require the voiceprint Repository-URI to be specified in the START-SESSION. In many usage scenarios, however, the system does not know the speaker's claimed identity until a recognition operation has, for example, recognized an account number to which the user desires access. In order to allow the first few utterances of a dialog to be both recognized and verified, the verifier resource on the MRCPv2 server retains a buffer. In this buffer, the MRCPv2 server accumulates recognized utterances. The client can later execute a verification method and apply the buffered utterances to the current verification session.
トレーニングセッションと検証セッションの両方で、声紋のリポジトリURIをSTART-SESSIONで指定する必要があります。しかし、多くの使用シナリオでは、システムは、認識操作が、たとえば、ユーザーがアクセスを希望するアカウント番号を認識するまで、話者の主張するアイデンティティを知りません。ダイアログの最初の数発話を認識および検証できるようにするために、MRCPv2サーバーの検証リソースはバッファを保持します。このバッファでは、MRCPv2サーバーは認識された発話を蓄積します。クライアントは後で検証メソッドを実行し、バッファされた発話を現在の検証セッションに適用できます。
Some voice user interfaces may require additional user input that should not be subject to verification. For example, the user's input may have been recognized with low confidence and thus require a confirmation cycle. In such cases, the client SHOULD NOT execute the VERIFY or VERIFY-FROM-BUFFER methods to collect and analyze the caller's input. A separate recognizer resource can analyze the caller's response without any participation by the verifier resource.
一部の音声ユーザーインターフェイスでは、検証の対象とならない追加のユーザー入力が必要になる場合があります。たとえば、ユーザーの入力が低い信頼度で認識されたため、確認サイクルが必要な場合があります。このような場合、クライアントはVERIFYまたはVERIFY-FROM-BUFFERメソッドを実行して、呼び出し元の入力を収集および分析するべきではありません（SHOULD NOT）。別の認識リソースが、検証リソースの関与なしに呼び出し元の応答を分析できます。
Once the following conditions have been met:
以下の条件が満たされると、
1. the voiceprint identity has been successfully established through the Voiceprint-Identifier header fields of the START-SESSION method, and
1. START-SESSIONメソッドのVoiceprint-Identifierヘッダーフィールドを使用して、声紋IDが正常に確立されている。
2. the verification mode has been set to one of "train" or "verify",
2. 検証モードが「トレーニング」または「検証」のいずれかに設定されている、
the verifier resource can begin providing verification information during verification operations. If the verifier resource does not reach one of the two major states ("train" or "verify") , it MUST report an error condition in the MRCPv2 status code to indicate why the verifier resource is not ready for the corresponding usage.
検証リソースは、検証操作中に検証情報の提供を開始できます。検証リソースが2つの主要な状態（「train」または「verify」）のいずれかに到達しない場合、検証リソースが対応する使用の準備ができていない理由を示すために、MRCPv2ステータスコードでエラー状態を報告する必要があります。
The value of verification-mode is persistent within a verification session. If the client attempts to change the mode during a verification session, the verifier resource reports an error and the mode retains its current value.
検証モードの値は、検証セッション内で永続的です。検証セッション中にクライアントがモードを変更しようとすると、検証リソースはエラーを報告し、モードは現在の値を保持します。
verification-mode = "Verification-Mode" ":" verification-mode-string
検証モード= "検証モード" "："検証モード文字列
verification-mode-string = "train" / "verify"
検証モード文字列= "train" / "verify"
This header field indicates the desired behavior of the verifier resource after a successful verification operation. If the value of this header field is "true", the server SHOULD use audio collected during the verification session to update the voiceprint to account for ongoing changes in a speaker's incoming speech characteristics, unless local policy prohibits updating the voiceprint. If the value is "false" (the default), the server MUST NOT update the voiceprint. This header field MAY occur in the START-SESSION method.
このヘッダーフィールドは、検証操作が成功した後の検証リソースの望ましい動作を示します。このヘッダーフィールドの値が「true」の場合、ローカルポリシーで声紋の更新が禁止されていない限り、サーバーは検証セッション中に収集された音声を使用して声紋を更新し、スピーカーの着信音声特性の進行中の変更を考慮に入れる必要があります。値が「false」（デフォルト）の場合、サーバーは声紋を更新してはなりません（MUST NOT）。このヘッダーフィールドは、START-SESSIONメソッドで発生する場合があります。
adapt-model = "Adapt-Model" ":" BOOLEAN CRLF
適応モデル= "適応モデル" "："ブールCRLF
The Abort-Model header field indicates the desired behavior of the verifier resource upon session termination. If the value of this header field is "true", the server MUST discard any pending changes to a voiceprint due to verification training or verification adaptation. If the value is "false" (the default), the server MUST commit any pending changes for a training session or a successful verification session to the voiceprint repository. A value of "true" for Abort-Model overrides a value of "true" for the Adapt-Model header field. This header field MAY occur in the END-SESSION method.
Abort-Modelヘッダーフィールドは、セッション終了時の検証リソースの望ましい動作を示します。このヘッダーフィールドの値が "true"の場合、サーバーは、検証トレーニングまたは検証適応による声紋への保留中の変更を破棄する必要があります。値が「false」（デフォルト）の場合、サーバーは、トレーニングセッションまたは成功した検証セッションの保留中の変更をすべて音声プリントリポジトリにコミットする必要があります。 Abort-Modelの「true」の値は、Adapt-Modelヘッダーフィールドの「true」の値をオーバーライドします。このヘッダーフィールドは、END-SESSIONメソッドで発生する場合があります。
abort-model = "Abort-Model" ":" BOOLEAN CRLF
abort-model = "Abort-Model" "："ブールCRLF
The Min-Verification-Score header field, when used with a verifier resource through a SET-PARAMS, GET-PARAMS, or START-SESSION method, determines the minimum verification score for which a verification decision of "accepted" may be declared by the server. This is a float value between -1.0 and 1.0. The default value for this header field is implementation specific.
Min-Verification-Scoreヘッダーフィールドは、SET-PARAMS、GET-PARAMS、またはSTART-SESSIONメソッドを介して検証リソースと一緒に使用される場合、「受け入れられた」という検証決定が宣言される最小検証スコアを決定します。サーバ。これは、-1.0〜1.0の浮動小数点値です。このヘッダーフィールドのデフォルト値は実装固有です。
min-verification-score = "Min-Verification-Score" ":" [ %x2D ] FLOAT CRLF
min-verification-score = "Min-Verification-Score" "：" [％x2D] FLOAT CRLF
The Num-Min-Verification-Phrases header field is used to specify the minimum number of valid utterances before a positive decision is given for verification. The value for this header field is an integer and the default value is 1. The verifier resource MUST NOT declare a verification 'accepted' unless Num-Min-Verification-Phrases valid utterances have been received. The minimum value is 1. This header field MAY occur in START-SESSION, SET-PARAMS, or GET-PARAMS.
Num-Min-Verification-Phrasesヘッダーフィールドは、検証のために肯定的な決定が行われる前の有効な発話の最小数を指定するために使用されます。このヘッダーフィールドの値は整数で、デフォルト値は1です。検証リソースは、Num-Min-Verification-Phrasesの有効な発話が受信されない限り、検証が「受け入れられた」と宣言してはなりません。最小値は1です。このヘッダーフィールドは、START-SESSION、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
num-min-verification-phrases = "Num-Min-Verification-Phrases" ":" 1*19DIGIT CRLF
num-min-verification-phrases = "Num-Min-Verification-Phrases" "：" 1 * 19DIGIT CRLF
The Num-Max-Verification-Phrases header field is used to specify the number of valid utterances required before a decision is forced for verification. The verifier resource MUST NOT return a decision of 'undecided' once Num-Max-Verification-Phrases have been collected and used to determine a verification score. The value for this header field is an integer and the minimum value is 1. The default value is implementation specific. This header field MAY occur in START-SESSION, SET-PARAMS, or GET-PARAMS.
Num-Max-Verification-Phrasesヘッダーフィールドは、確認のために決定が強制される前に必要な有効な発話の数を指定するために使用されます。検証リソースは、Num-Max-Verification-Phrasesが収集され、検証スコアを決定するために使用されると、「未決定」の決定を返してはなりません（MUST NOT）。このヘッダーフィールドの値は整数で、最小値は1です。デフォルト値は実装固有です。このヘッダーフィールドは、START-SESSION、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
num-max-verification-phrases = "Num-Max-Verification-Phrases" ":" 1*19DIGIT CRLF
num-max-verification-phrases = "Num-Max-Verification-Phrases" "：" 1 * 19DIGIT CRLF
The No-Input-Timeout header field sets the length of time from the start of the verification timers (see START-INPUT-TIMERS) until the VERIFICATION-COMPLETE server event message declares that no input has been received (i.e., has a Completion-Cause of no-input-timeout). The value is in milliseconds. This header field MAY occur in VERIFY, SET-PARAMS, or GET-PARAMS. The value for this header field ranges from 0 to an implementation-specific maximum value. The default value for this header field is implementation specific.
No-Input-Timeoutヘッダーフィールドは、検証タイマー（START-INPUT-TIMERSを参照）の開始から、VERIFICATION-COMPLETEサーバーイベントメッセージで入力が受信されなかった（つまり、Completion- no-input-timeoutの原因）。値はミリ秒単位です。このヘッダーフィールドは、VERIFY、SET-PARAMS、またはGET-PARAMSで発生する場合があります。このヘッダーフィールドの値の範囲は、0から実装固有の最大値までです。このヘッダーフィールドのデフォルト値は実装固有です。
no-input-timeout = "No-Input-Timeout" ":" 1*19DIGIT CRLF
This header field allows the client to request that the verifier resource save the audio stream that was used for verification/ identification. The verifier resource MUST attempt to record the audio and make it available to the client in the form of a URI returned in the Waveform-URI header field in the VERIFICATION-COMPLETE event. If there was an error in recording the stream, or the audio content is otherwise not available, the verifier resource MUST return an empty Waveform-URI header field. The default value for this header field is "false". This header field MAY appear in the VERIFY method. Note that this header field does not appear in the VERIFY-FROM-BUFFER method since it only controls whether or not to save the waveform for live verification/identification operations.
このヘッダーフィールドを使用すると、クライアントは検証リソースが検証/識別に使用されたオーディオストリームを保存することを要求できます。ベリファイアリソースは、音声を記録し、VERIFICATION-COMPLETEイベントのWaveform-URIヘッダーフィールドで返されるURIの形式でクライアントが利用できるようにする必要があります。ストリームの記録中にエラーが発生した場合、またはオーディオコンテンツが利用できない場合、検証リソースは空のWaveform-URIヘッダーフィールドを返す必要があります。このヘッダーフィールドのデフォルト値は「false」です。このヘッダーフィールドは、VERIFYメソッドで表示される場合があります。このヘッダーフィールドは、ライブ検証/識別操作のために波形を保存するかどうかを制御するだけなので、VERIFY-FROM-BUFFERメソッドには表示されません。
save-waveform = "Save-Waveform" ":" BOOLEAN CRLF
save-waveform = "Save-Waveform" "：" BOOLEAN CRLF
This header field MAY be specified in the SET-PARAMS, GET-PARAMS, or the VERIFY methods and tells the server resource the media type of the captured audio or video such as the one captured and returned by the Waveform-URI header field.
このヘッダーフィールドは、SET-PARAMS、GET-PARAMS、またはVERIFYメソッドで指定される場合があり、Waveform-URIヘッダーフィールドによってキャプチャされて返されたものなど、キャプチャされたオーディオまたはビデオのメディアタイプをサーバーリソースに通知します。
media-type = "Media-Type" ":" media-type-value CRLF
media-type = "Media-Type" "：" media-type-value CRLF
If the Save-Waveform header field is set to "true", the verifier resource MUST attempt to record the incoming audio stream of the verification into a file and provide a URI for the client to access it. This header field MUST be present in the VERIFICATION-COMPLETE event if the Save-Waveform header field was set to true by the client. The value of the header field MUST be empty if there was some error condition preventing the server from recording. Otherwise, the URI generated by the server MUST be globally unique across the server and all its verification sessions. The content MUST be available via the URI until the verification session ends. Since the Save-Waveform header field applies only to live verification/identification operations, the server can return the Waveform-URI only in the VERIFICATION-COMPLETE event for live verification/identification operations.
Save-Waveformヘッダーフィールドが「true」に設定されている場合、検証リソースは検証の着信オーディオストリームをファイルに記録し、クライアントがアクセスするためのURIを提供する必要があります。 Save-Waveformヘッダーフィールドがクライアントによってtrueに設定されている場合、このヘッダーフィールドはVERIFICATION-COMPLETEイベントに存在する必要があります。サーバーが記録できないエラー条件が発生した場合、ヘッダーフィールドの値は空でなければなりません。それ以外の場合、サーバーによって生成されたURIは、サーバーとそのすべての検証セッションにわたってグローバルに一意である必要があります。コンテンツは、検証セッションが終了するまで、URIを介して利用できる必要があります。 Save-Waveformヘッダーフィールドはライブ検証/識別操作にのみ適用されるため、サーバーはライブ検証/識別操作のVERIFICATION-COMPLETEイベントでのみWaveform-URIを返すことができます。
The server MUST also return the size in octets and the duration in milliseconds of the recorded audio waveform as parameters associated with the header field.
サーバーは、ヘッダーフィールドに関連付けられたパラメーターとして、記録されたオーディオ波形のオクテット単位のサイズとミリ秒単位の期間も返す必要があります。
waveform-uri = "Waveform-URI" ":" ["<" uri ">"
";" "size" "=" 1*19DIGIT
";" "duration" "=" 1*19DIGIT] CRLF
This header field MUST be returned in QUERY-VOICEPRINT and DELETE-VOICEPRINT responses. This is the status of the voiceprint specified in the QUERY-VOICEPRINT method. For the DELETE-VOICEPRINT method, this header field indicates the status of the voiceprint at the moment the method execution started.
このヘッダーフィールドは、QUERY-VOICEPRINTおよびDELETE-VOICEPRINT応答で返される必要があります。これは、QUERY-VOICEPRINTメソッドで指定された声紋のステータスです。 DELETE-VOICEPRINTメソッドの場合、このヘッダーフィールドは、メソッドの実行が開始されたときの声紋のステータスを示します。
voiceprint-exists = "Voiceprint-Exists" ":" BOOLEAN CRLF
voiceprint-exists = "Voiceprint-Exists" "：" BOOLEAN CRLF
This header field is used to indicate that this utterance could be later considered for speaker verification. This way, a client can request the server to buffer utterances while doing regular recognition or verification activities, and speaker verification can later be requested on the buffered utterances. This header field is optional in the RECOGNIZE, VERIFY, and RECORD methods. The default value for this header field is "false".
このヘッダーフィールドは、この発話が後で話者の検証に考慮されることを示すために使用されます。このようにして、クライアントはサーバーに通常の認識または検証アクティビティを実行しながら発話をバッファするように要求でき、バッファされた発話に対して話者の検証を後で要求できます。このヘッダーフィールドは、RECOGNIZE、VERIFY、およびRECORDメソッドではオプションです。このヘッダーフィールドのデフォルト値は「false」です。
ver-buffer-utterance = "Ver-Buffer-Utterance" ":" BOOLEAN CRLF
ver-buffer-utterance = "Ver-Buffer-Utterance" "：" BOOLEAN CRLF
This header field specifies stored audio content that the client requests the server to fetch and process according to the current verification mode, either to train the voiceprint or verify a claimed identity. This header field enables the client to implement the buffering use case where the recognizer and verifier resources are in different sessions and the verification buffer technique cannot be used. It MAY be specified on the VERIFY request.
このヘッダーフィールドは、クライアントがサーバーに現在の検証モードに従ってフェッチして処理するように要求する格納されたオーディオコンテンツを指定します。このヘッダーフィールドにより、クライアントは、認識リソースと検証リソースが異なるセッションにあり、検証バッファー技術を使用できない場合のバッファリングの使用例を実装できます。これは、VERIFY要求で指定される場合があります。
input-waveform-uri = "Input-Waveform-URI" ":" uri CRLF
input-waveform-uri = "Input-Waveform-URI" "：" uri CRLF
This header field MUST be part of a VERIFICATION-COMPLETE event from the verifier resource to the client. This indicates the cause of VERIFY or VERIFY-FROM-BUFFER method completion. This header field MUST be sent in the VERIFY, VERIFY-FROM-BUFFER, and QUERY-VOICEPRINT responses, if they return with a failure status and a COMPLETE state. In the ABNF below, the 'cause-code' contains a numerical value selected from the Cause-Code column of the following table. The 'cause-name' contains the corresponding token selected from the Cause-Name column.
このヘッダーフィールドは、検証リソースからクライアントへのVERIFICATION-COMPLETEイベントの一部である必要があります。これは、VERIFYまたはVERIFY-FROM-BUFFERメソッドが完了した原因を示しています。このヘッダーフィールドは、VERIFY、VERIFY-FROM-BUFFER、およびQUERY-VOICEPRINT応答で送信される必要があります（失敗のステータスとCOMPLETE状態で返される場合）。以下のABNFでは、「原因コード」には、次の表の「原因コード」列から選択された数値が含まれています。 「原因名」には、原因名列から選択された対応するトークンが含まれています。
completion-cause = "Completion-Cause" ":" cause-code SP
cause-name CRLF
cause-code = 3DIGIT
cause-name = *VCHAR
+------------+--------------------------+---------------------------+
| Cause-Code | Cause-Name | Description |
+------------+--------------------------+---------------------------+
| 000 | success | VERIFY or |
| | | VERIFY-FROM-BUFFER |
| | | request completed |
| | | successfully. The verify |
| | | decision can be |
| | | "accepted", "rejected", |
| | | or "undecided". |
| 001 | error | VERIFY or |
| | | VERIFY-FROM-BUFFER |
| | | request terminated |
| | | prematurely due to a |
| | | verifier resource or |
| | | system error. |
| 002 | no-input-timeout | VERIFY request completed |
| | | with no result due to a |
| | | no-input-timeout. |
| 003 | too-much-speech-timeout | VERIFY request completed |
| | | with no result due to too |
| | | much speech. |
| 004 | speech-too-early | VERIFY request completed |
| | | with no result due to |
| | | speech too soon. |
| 005 | buffer-empty | VERIFY-FROM-BUFFER |
| | | request completed with no |
| | | result due to empty |
| | | buffer. |
| 006 | out-of-sequence | Verification operation |
| | | failed due to |
| | | out-of-sequence method |
| | | invocations, for example, |
| | | calling VERIFY before |
| | | QUERY-VOICEPRINT. |
| 007 | repository-uri-failure | Failure accessing |
| | | Repository URI. |
| 008 | repository-uri-missing | Repository-URI is not |
| | | specified. |
| 009 | voiceprint-id-missing | Voiceprint-Identifier is |
| | | not specified. |
| 010 | voiceprint-id-not-exist | Voiceprint-Identifier |
| | | does not exist in the |
| | | voiceprint repository. |
| 011 | speech-not-usable | VERIFY request completed |
| | | with no result because |
| | | the speech was not usable |
| | | (too noisy, too short, |
| | | etc.) |
+------------+--------------------------+---------------------------+
This header field MAY be specified in a VERIFICATION-COMPLETE event coming from the verifier resource to the client. It contains the reason text behind the VERIFY request completion. This header field communicates text describing the reason for the failure.
このヘッダーフィールドは、検証リソースからクライアントに送られるVERIFICATION-COMPLETEイベントで指定される場合があります。これには、VERIFY要求の完了の背後にある理由テキストが含まれています。このヘッダーフィールドは、失敗の理由を説明するテキストを伝えます。
The completion reason text is provided for client use in logs and for debugging and instrumentation purposes. Clients MUST NOT interpret the completion reason text.
完了理由のテキストは、クライアントがログで使用するため、およびデバッグと計測の目的で提供されます。クライアントは完了理由テキストを解釈してはなりません。
completion-reason = "Completion-Reason" ":" quoted-string CRLF
completion-reason = "Completion-Reason" "："引用文字列CRLF
This header field is the same as the one described for the Recognizer resource. See Section 9.4.15. This header field MAY occur in VERIFY, SET-PARAMS, or GET-PARAMS.
このヘッダーフィールドは、Recognizerリソースについて説明したものと同じです。セクション9.4.15を参照してください。このヘッダーフィールドは、VERIFY、SET-PARAMS、またはGET-PARAMSで発生する場合があります。
This header field is the same as the one described for the Recognizer resource. See Section 9.4.23. This header field MAY be specified in a VERIFY request.
このヘッダーフィールドは、Recognizerリソースについて説明したものと同じです。セクション9.4.23を参照してください。このヘッダーフィールドは、VERIFYリクエストで指定される場合があります。
This header field MUST be sent in a STOP request to indicate whether or not to abort a VERIFY method in progress. A value of "true" requests the server to discard the results. A value of "false" requests the server to return in the STOP response the verification results obtained up to the point it received the STOP request.
このヘッダーフィールドは、進行中のVERIFYメソッドを中止するかどうかを示すために、STOPリクエストで送信する必要があります。 「true」の値は、サーバーに結果を破棄するように要求します。 「false」の値は、サーバーがSTOP要求を受信した時点までに取得された検証結果をSTOP応答で返すようサーバーに要求します。
abort-verification = "Abort-Verification " ":" BOOLEAN CRLF
abort-verification = "Abort-Verification" "：" BOOLEAN CRLF
This header field MAY be sent as part of a VERIFY request. A value of "false" tells the verifier resource to start the VERIFY operation but not to start the no-input timer yet. The verifier resource MUST NOT start the timers until the client sends a START-INPUT-TIMERS request to the resource. This is useful in the scenario when the verifier and synthesizer resources are not part of the same session. In this scenario, when a kill-on-barge-in prompt is being played, the client may want the VERIFY request to be simultaneously active so that it can detect and implement kill-on-barge-in (see Section 8.4.2). But at the same time, the client doesn't want the verifier resource to start the no-input timers until the prompt is finished. The default value is "true".
このヘッダーフィールドは、VERIFYリクエストの一部として送信される場合があります。 「false」の値は、検証リソースにVERIFY操作を開始するように指示しますが、まだ入力なしタイマーを開始しないように指示します。クライアントがリソースにSTART-INPUT-TIMERSリクエストを送信するまで、検証リソースはタイマーを開始してはなりません（MUST NOT）。これは、ベリファイアとシンセサイザのリソースが同じセッションの一部ではない場合に役立ちます。このシナリオでは、kill-on-barge-inプロンプトが再生されているときに、クライアントがVERIFY要求を同時にアクティブにして、kill-on-barge-inを検出して実装できるようにする場合があります（セクション8.4.2を参照）。 。しかし同時に、プロンプトが終了するまで、クライアントは検証リソースが無入力タイマーを開始することを望みません。デフォルト値は「true」です。
start-input-timers = "Start-Input-Timers" ":" BOOLEAN CRLF
start-input-timers = "Start-Input-Timers" "：" BOOLEAN CRLF
A verification response or event message can carry additional data as described in the following subsection.
検証応答またはイベントメッセージには、次のサブセクションで説明するように、追加のデータを含めることができます。
Verification results are returned to the client in the message body of the VERIFICATION-COMPLETE event or the GET-INTERMEDIATE-RESULT response message as described in Section 6.3. Element and attribute descriptions for the verification portion of the NLSML format are provided in Section 11.5.2 with a normative definition of the schema in Section 16.3.
検証結果は、セクション6.3で説明されているように、VERIFICATION-COMPLETEイベントのメッセージ本文またはGET-INTERMEDIATE-RESULT応答メッセージでクライアントに返されます。 NLSML形式の検証部分の要素と属性の説明は、セクション11.6.3にスキーマの規範的な定義とともにセクション11.5.2に記載されています。
All verification elements are contained within a single <verification-result> element under <result>. The elements are described below and have the schema defined in Section 16.2. The following elements are defined:
すべての検証要素は、<result>の下の単一の<verification-result>要素内に含まれています。要素については以下で説明し、セクション16.2で定義されているスキーマを使用します。次の要素が定義されています。
1. <voiceprint>
1. <声紋>
2. <incremental>
2. <増分>
3. <cumulative>
3. <累計>
4. <decision>
4. <決定>
5. <utterance-length>
5. <発声長>
6. <device>
6. <デバイス>
7. <gender>
7. <性別>
8. <adapted>
8. <適応>
9. <verification-score>
9. <検証スコア>
10. <vendor-specific-results>
10. <ベンダー固有の結果>
This element in the verification results provides information on how the speech data matched a single voiceprint. The result data returned MAY have more than one such entity in the case of identification or multi-verification. Each <voiceprint> element and the XML data within the element describe verification result information for how well the speech data matched that particular voiceprint. The list of <voiceprint> element data are ordered according to their cumulative verification match scores, with the highest score first.
検証結果のこの要素は、音声データが単一の声紋とどのように一致したかに関する情報を提供します。返される結果データには、識別またはマルチ検証の場合に、そのようなエンティティが複数ある場合があります。各<voiceprint>要素と要素内のXMLデータは、音声データが特定の声紋とどの程度一致しているかの検証結果情報を記述します。 <voiceprint>要素データのリストは、累積検証照合スコアに従って並べられ、最も高いスコアが最初になります。
Within each <voiceprint> element there MUST be a <cumulative> element with the cumulative scores of how well multiple utterances matched the voiceprint.
各<voiceprint>要素内には、複数の発話が声紋とどれだけよく一致したかについての累積スコアを持つ<cumulative>要素が存在する必要があります。
The first <voiceprint> element MAY contain an <incremental> element with the incremental scores of how well the last utterance matched the voiceprint.
最初の<voiceprint>要素には、最後の発声が声紋とどの程度一致したかを示す増分スコアを持つ<incremental>要素を含めることができます。
This element is found within the <incremental> or <cumulative> element within the verification results. Its value indicates the verification decision. It can have the values of "accepted", "rejected", or "undecided".
この要素は、検証結果の<incremental>または<cumulative>要素内にあります。その値は検証の決定を示します。 「受け入れ」、「拒否」、または「未決定」の値を持つことができます。
This element MAY occur within either the <incremental> or <cumulative> elements within the first <voiceprint> element. Its value indicates the size in milliseconds, respectively, of the last utterance or the cumulated set of utterances.
この要素は、最初の<voiceprint>要素内の<incremental>または<cumulative>要素内で発生する場合があります。その値は、最後の発話または累積された発話のセットのサイズをそれぞれミリ秒単位で示します。
This element is found within the <incremental> or <cumulative> element within the verification results. Its value indicates the apparent type of device used by the caller as determined by the verifier resource. It can have the values of "cellular-phone", "electret-phone", "carbon-button-phone", or "unknown".
この要素は、検証結果の<incremental>または<cumulative>要素内にあります。その値は、ベリファイアリソースによって決定される、発信者が使用するデバイスの見かけ上のタイプを示します。 「携帯電話」、「エレクトレット電話」、「カーボンボタン電話」、または「不明」の値をとることができます。
This element is found within the <incremental> or <cumulative> element within the verification results. Its value indicates the apparent gender of the speaker as determined by the verifier resource. It can have the values of "male", "female", or "unknown".
この要素は、検証結果の<incremental>または<cumulative>要素内にあります。その値は、検証者リソースによって決定される話者の見かけの性別を示します。 「男性」、「女性」、または「不明」の値を持つことができます。
This element is found within the first <voiceprint> element within the verification results. When verification is trying to confirm the voiceprint, this indicates if the voiceprint has been adapted as a consequence of analyzing the source utterances. It is not returned during verification training. The value can be "true" or "false".
この要素は、検証結果の最初の<voiceprint>要素内にあります。検証が声紋を確認しようとしている場合、これは、声紋がソース発話の分析の結果として適合されたかどうかを示します。検証トレーニング中には返されません。値は「true」または「false」です。
This element is found within the <incremental> or <cumulative> element within the verification results. Its value indicates the score of the last utterance as determined by verification.
この要素は、検証結果の<incremental>または<cumulative>要素内にあります。その値は、検証によって決定された最後の発話のスコアを示します。
During verification, the higher the score, the more likely it is that the speaker is the same one as the one who spoke the voiceprint utterances. During training, the higher the score, the more likely the speaker is to have spoken all of the analyzed utterances. The value is a floating point between -1.0 and 1.0. If there are no such utterances, the score is -1. Note that the verification score is not a probability value.
検証中、スコアが高いほど、声紋の発話を話したのと同じ話者である可能性が高くなります。トレーニング中、スコアが高いほど、分析されたすべての発話を話者が話している可能性が高くなります。値は-1.0と1.0の間の浮動小数点です。そのような発話がない場合、スコアは-1になります。検証スコアは確率値ではないことに注意してください。
MRCPv2 servers MAY send verification results that contain implementation-specific data that augment the information provided by the MRCPv2-defined elements. Such data might be useful to clients who have private knowledge of how to interpret these schema extensions. Implementation-specific additions to the verification results schema MUST belong to the vendor's own namespace. In the result structure, either they MUST be indicated by a namespace prefix declared within the result, or they MUST be children of an element identified as belonging to the respective namespace.
MRCPv2サーバーは、MRCPv2定義の要素によって提供される情報を補強する実装固有のデータを含む検証結果を送信する場合があります。このようなデータは、これらのスキーマ拡張を解釈する方法について個人的な知識を持つクライアントにとって役立つ場合があります。検証結果スキーマへの実装固有の追加は、ベンダー独自の名前空間に属している必要があります。結果構造では、それらは結果内で宣言された名前空間接頭辞によって示されなければならない（MUST）か、またはそれぞれの名前空間に属していると識別された要素の子である必要があります。
The following example shows the results of three voiceprints. Note that the first one has crossed the verification score threshold, and the speaker has been accepted. The voiceprint was also adapted with the most recent utterance.
次の例は、3つの声紋の結果を示しています。最初の1つが検証スコアのしきい値を超え、スピーカーが受け入れられたことに注意してください。声紋も最新の発話に合わせて調整されました。
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="What-Grammar-URI">
<verification-result>
<voiceprint id="johnsmith">
<adapted> true </adapted>
<incremental>
<utterance-length> 500 </utterance-length>
<device> cellular-phone </device>
<gender> male </gender>
<decision> accepted </decision>
<verification-score> 0.98514 </verification-score>
</incremental>
<cumulative>
<utterance-length> 10000 </utterance-length>
<device> cellular-phone </device>
<gender> male </gender>
<decision> accepted </decision>
<verification-score> 0.96725</verification-score>
</cumulative>
</voiceprint>
<voiceprint id="marysmith">
<cumulative>
<verification-score> 0.93410 </verification-score>
</cumulative>
</voiceprint>
<voiceprint uri="juniorsmith">
<cumulative>
<verification-score> 0.74209 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</result>
Verification Results Example 1
検証結果例1
In this next example, the verifier has enough information to decide to reject the speaker.
この次の例では、検証者は話者を拒否することを決定するのに十分な情報を持っています。
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:xmpl="http://www.example.org/2003/12/mrcpv2"
grammar="What-Grammar-URI">
<verification-result>
<voiceprint id="johnsmith">
<incremental>
<utterance-length> 500 </utterance-length>
<device> cellular-phone </device>
<gender> male </gender>
<verification-score> 0.88514 </verification-score>
<xmpl:raspiness> high </xmpl:raspiness>
<xmpl:emotion> sadness </xmpl:emotion>
</incremental>
<cumulative>
<utterance-length> 10000 </utterance-length>
<device> cellular-phone </device>
<gender> male </gender>
<decision> rejected </decision>
<verification-score> 0.9345 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</result>
Verification Results Example 2
検証結果例2
The START-SESSION method starts a speaker verification or speaker identification session. Execution of this method places the verifier resource into its initial state. If this method is called during an ongoing verification session, the previous session is implicitly aborted. If this method is invoked when VERIFY or VERIFY-FROM-BUFFER is active, the method fails and the server returns a status-code of 402.
START-SESSIONメソッドは、話者認証または話者識別セッションを開始します。このメソッドを実行すると、検証リソースが初期状態になります。進行中の検証セッション中にこのメソッドが呼び出されると、前のセッションは暗黙的に中止されます。 VERIFYまたはVERIFY-FROM-BUFFERがアクティブなときにこのメソッドが呼び出されると、メソッドは失敗し、サーバーはステータスコード402を返します。
Upon completion of the START-SESSION method, the verifier resource MUST have terminated any ongoing verification session and cleared any voiceprint designation.
START-SESSIONメソッドが完了すると、検証リソースは進行中の検証セッションをすべて終了し、声紋の指定をすべてクリアする必要があります。
A verification session is associated with the voiceprint repository to be used during the session. This is specified through the Repository-URI header field (see Section 11.4.1).
検証セッションは、セッション中に使用される声紋リポジトリに関連付けられています。これは、Repository-URIヘッダーフィールドで指定されます（セクション11.4.1を参照）。
The START-SESSION method also establishes, through the Voiceprint-Identifier header field, which voiceprints are to be matched or trained during the verification session. If this is an Identification session or if the client wants to do Multi-Verification, the Voiceprint-Identifier header field contains a list of semicolon-separated voiceprint identifiers.
また、START-SESSIONメソッドは、Voiceprint-Identifierヘッダーフィールドを介して、検証セッション中にどの声紋を照合またはトレーニングするかを確立します。これが識別セッションである場合、またはクライアントがマルチ検証を実行したい場合、Voiceprint-Identifierヘッダーフィールドには、セミコロンで区切られた声紋識別子のリストが含まれます。
The Adapt-Model header field MAY also be present in the START-SESSION request to indicate whether or not to adapt a voiceprint based on data collected during the session (if the voiceprint verification phase succeeds). By default, the voiceprint model MUST NOT be adapted with data from a verification session.
Adapt-Modelヘッダーフィールドは、セッション中に収集されたデータに基づいて声紋を適合させるかどうかを示すためにSTART-SESSIONリクエストにも存在する場合があります（声紋検証フェーズが成功した場合）。デフォルトでは、声紋モデルは検証セッションからのデータで適合してはいけません。
The START-SESSION also determines whether the session is for a train or verify of a voiceprint. Hence, the Verification-Mode header field MUST be sent in every START-SESSION request. The value of the Verification-Mode header field MUST be one of either "train" or "verify".
START-SESSIONは、セッションが電車用か声紋の確認用かを決定します。したがって、検証モードヘッダーフィールドは、すべてのSTART-SESSIONリクエストで送信する必要があります。 Verification-Modeヘッダーフィールドの値は、「train」または「verify」のいずれかである必要があります。
Before a verification/identification session is started, the client may only request that VERIFY-ROLLBACK and generic SET-PARAMS and GET-PARAMS operations be performed on the verifier resource. The server MUST return status-code 402 "Method not valid in this state" for all other verification operations.
検証/識別セッションが開始される前に、クライアントは、VERIFY-ROLLBACKおよび一般的なSET-PARAMSおよびGET-PARAMS操作が検証リソースで実行されることのみを要求できます。他のすべての検証操作では、サーバーはステータスコード402「この状態ではメソッドは無効です」を返す必要があります。
A verifier resource MUST NOT have more than a single session active at one time.
検証リソースは、一度に複数のセッションをアクティブにすることはできません。
C->S: MRCP/2.0 ... START-SESSION 314161
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/voiceprintdbase/
Voiceprint-Mode:verify
Voiceprint-Identifier:johnsmith.voiceprint
Adapt-Model:true
S->C: MRCP/2.0 ... 314161 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
The END-SESSION method terminates an ongoing verification session and releases the verification voiceprint resources. The session may terminate in one of three ways:
END-SESSIONメソッドは、進行中の検証セッションを終了し、検証声紋リソースを解放します。セッションは次の3つの方法のいずれかで終了します。
1. abort - the voiceprint adaptation or creation may be aborted so that the voiceprint remains unchanged (or is not created).
1. abort-声紋の変更または作成を中止して、声紋を変更しない（または作成しない）ことができます。
2. commit - when terminating a voiceprint training session, the new voiceprint is committed to the repository.
2. commit-声紋トレーニングセッションを終了すると、新しい声紋がリポジトリにコミットされます。
3. adapt - an existing voiceprint is modified using a successful verification.
3. 適応-既存の声紋は、検証が成功したときに変更されます。
The Abort-Model header field MAY be included in the END-SESSION to control whether or not to abort any pending changes to the voiceprint. The default behavior is to commit (not abort) any pending changes to the designated voiceprint.
Abort-Modelヘッダーフィールドは、声紋に対する保留中の変更を中止するかどうかを制御するために、END-SESSIONに含めることができます。デフォルトの動作では、指定された声紋に対する保留中の変更をコミットします（中止しない）。
The END-SESSION method may be safely executed multiple times without first executing the START-SESSION method. Any additional executions of this method without an intervening use of the START-SESSION method have no effect on the verifier resource.
END-SESSIONメソッドは、最初にSTART-SESSIONメソッドを実行しなくても、複数回安全に実行できます。 START-SESSIONメソッドを使用せずにこのメソッドをさらに実行しても、ベリファイアリソースには影響しません。
The following example assumes there is either a training session or a verification session in progress.
次の例では、トレーニングセッションまたは検証セッションが進行中であると想定しています。
C->S: MRCP/2.0 ... END-SESSION 314174
Channel-Identifier:32AECB23433801@speakverify
Abort-Model:true
S->C: MRCP/2.0 ... 314174 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
The QUERY-VOICEPRINT method is used to get status information on a particular voiceprint and can be used by the client to ascertain if a voiceprint or repository exists and if it contains trained voiceprints.
QUERY-VOICEPRINTメソッドは、特定の声紋のステータス情報を取得するために使用され、クライアントが声紋またはリポジトリが存在するかどうか、および訓練された声紋が含まれているかどうかを確認するために使用できます。
The response to the QUERY-VOICEPRINT request contains an indication of the status of the designated voiceprint in the Voiceprint-Exists header field, allowing the client to determine whether to use the current voiceprint for verification, train a new voiceprint, or choose a different voiceprint.
QUERY-VOICEPRINT要求への応答には、Voiceprint-Existsヘッダーフィールドに指定された声紋のステータスの表示が含まれるため、クライアントは、確認のために現在の声紋を使用するか、新しい声紋をトレーニングするか、別の声紋を選択するかを決定できます。 。
A voiceprint is completely specified by providing a repository location and a voiceprint identifier. The particular voiceprint or identity within the repository is specified by a string identifier that is unique within the repository. The Voiceprint-Identifier header field carries this unique voiceprint identifier within a given repository.
声紋は、リポジトリの場所と声紋の識別子を指定することで完全に指定されます。リポジトリ内の特定の声紋またはアイデンティティは、リポジトリ内で一意の文字列識別子によって指定されます。 Voiceprint-Identifierヘッダーフィールドは、特定のリポジトリ内でこの一意の声紋識別子を伝達します。
The following example assumes a verification session is in progress and the voiceprint exists in the voiceprint repository.
次の例では、検証セッションが進行中で、声紋が声紋リポジトリに存在することを前提としています。
C->S: MRCP/2.0 ... QUERY-VOICEPRINT 314168
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/voiceprints/
Voiceprint-Identifier:johnsmith.voiceprint
S->C: MRCP/2.0 ... 314168 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/voiceprints/
Voiceprint-Identifier:johnsmith.voiceprint
Voiceprint-Exists:true
The following example assumes that the URI provided in the Repository-URI header field is a bad URI.
次の例では、Repository-URIヘッダーフィールドで指定されたURIが不適切なURIであると想定しています。
C->S: MRCP/2.0 ... QUERY-VOICEPRINT 314168
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/bad-uri/
Voiceprint-Identifier:johnsmith.voiceprint
S->C: MRCP/2.0 ... 314168 405 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/bad-uri/
Voiceprint-Identifier:johnsmith.voiceprint
Completion-Cause:007 repository-uri-failure
The DELETE-VOICEPRINT method removes a voiceprint from a repository. This method MUST carry the Repository-URI and Voiceprint-Identifier header fields.
DELETE-VOICEPRINTメソッドは、声紋をリポジトリから削除します。このメソッドは、Repository-URIおよびVoiceprint-Identifierヘッダーフィールドを保持する必要があります。
An MRCPv2 server MUST reject a DELETE-VOICEPRINT request with a 401 status code unless the MRCPv2 client has been authenticated and authorized. Note that MRCPv2 does not have a standard mechanism for this. See Section 12.8.
MRCPv2クライアントが認証および承認されていない限り、MRCPv2サーバーは401ステータスコードでDELETE-VOICEPRINT要求を拒否する必要があります。 MRCPv2にはこのための標準メカニズムがないことに注意してください。セクション12.8を参照してください。
If the corresponding voiceprint does not exist, the DELETE-VOICEPRINT method MUST return a 200 status code.
対応する声紋が存在しない場合、DELETE-VOICEPRINTメソッドは200ステータスコードを返す必要があります。
The following example demonstrates a DELETE-VOICEPRINT operation to remove a specific voiceprint.
次の例は、特定の声紋を削除するDELETE-VOICEPRINT操作を示しています。
C->S: MRCP/2.0 ... DELETE-VOICEPRINT 314168
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/bad-uri/
Voiceprint-Identifier:johnsmith.voiceprint
S->C: MRCP/2.0 ... 314168 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
The VERIFY method is used to request that the verifier resource either train/adapt the voiceprint or verify/identify a claimed identity. If the voiceprint is new or was deleted by a previous DELETE-VOICEPRINT method, the VERIFY method trains the voiceprint. If the voiceprint already exists, it is adapted and not retrained by the VERIFY command.
VERIFYメソッドは、検証リソースが声紋をトレーニング/適応するか、主張されたアイデンティティを検証/識別することを要求するために使用されます。声紋が新しいか、以前のDELETE-VOICEPRINTメソッドによって削除された場合、VERIFYメソッドは声紋をトレーニングします。声紋がすでに存在する場合、声紋は調整され、VERIFYコマンドによって再トレーニングされません。
C->S: MRCP/2.0 ... VERIFY 543260
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 543260 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speakverify
When the VERIFY request completes, the MRCPv2 server MUST send a VERIFICATION-COMPLETE event to the client.
VERIFY要求が完了すると、MRCPv2サーバーはクライアントにVERIFICATION-COMPLETEイベントを送信する必要があります。
The VERIFY-FROM-BUFFER method directs the verifier resource to verify buffered audio against a voiceprint. Only one VERIFY or VERIFY-FROM-BUFFER method may be active for a verifier resource at a time.
VERIFY-FROM-BUFFERメソッドは、バッファリングされたオーディオを声紋に対して検証するようベリファイアリソースに指示します。ベリファイアリソースに対して一度にアクティブにできるVERIFYまたはVERIFY-FROM-BUFFERメソッドは1つだけです。
The buffered audio is not consumed by this method and thus VERIFY-FROM-BUFFER may be invoked multiple times by the client to attempt verification against different voiceprints.
バッファリングされたオーディオはこのメソッドでは消費されないため、クライアントがVERIFY-FROM-BUFFERを複数回呼び出して、異なる声紋に対する検証を試みる場合があります。
For the VERIFY-FROM-BUFFER method, the server MAY optionally return an IN-PROGRESS response before the VERIFICATION-COMPLETE event.
VERIFY-FROM-BUFFERメソッドの場合、サーバーは、オプションでVERIFICATION-COMPLETEイベントの前にIN-PROGRESS応答を返す場合があります。
When the VERIFY-FROM-BUFFER method is invoked and the verification buffer is in use by another resource sharing it, the server MUST return an IN-PROGRESS response and wait until the buffer is available to it. The verification buffer is owned by the verifier resource but is shared with write access from other input resources on the same session. Hence, it is considered to be in use if there is a read or write operation such as a RECORD or RECOGNIZE with the Ver-Buffer-Utterance header field set to "true" on a resource that shares this buffer. Note that if a RECORD or RECOGNIZE method returns with a failure cause code, the VERIFY-FROM-BUFFER request waiting to process that buffer MUST also fail with a Completion-Cause of 005 (buffer-empty).
VERIFY-FROM-BUFFERメソッドが呼び出され、検証バッファーがそれを共有する別のリソースによって使用されている場合、サーバーはIN-PROGRESS応答を返し、バッファーが使用可能になるまで待機する必要があります。検証バッファーは検証リソースによって所有されますが、同じセッションの他の入力リソースからの書き込みアクセスと共有されます。したがって、このバッファーを共有するリソースでVer-Buffer-Utteranceヘッダーフィールドが「true」に設定されたRECORDまたはRECOGNIZEなどの読み取りまたは書き込み操作がある場合、使用中と見なされます。 RECORDまたはRECOGNIZEメソッドが失敗の原因コードを返した場合、そのバッファーの処理を待機しているVERIFY-FROM-BUFFER要求も、005（buffer-empty）のCompletion-Causeで失敗することに注意してください。
The following example illustrates the usage of some buffering methods. In this scenario, the client first performed a live verification, but the utterance had been rejected. In the meantime, the utterance is also saved to the audio buffer. Then, another voiceprint is used to do verification against the audio buffer and the utterance is accepted. For the example, we assume both Num-Min-Verification-Phrases and Num-Max-Verification-Phrases are 1.
次の例は、いくつかのバッファリングメソッドの使用法を示しています。このシナリオでは、クライアントは最初にライブ検証を実行しましたが、発話は拒否されました。その間、発話も音声バッファに保存されます。次に、別の声紋を使用してオーディオバッファーと照合し、発声が受け入れられます。この例では、Num-Min-Verification-PhrasesとNum-Max-Verification-Phrasesの両方が1であると想定しています。
C->S: MRCP/2.0 ... START-SESSION 314161
Channel-Identifier:32AECB23433801@speakverify
Verification-Mode:verify
Adapt-Model:true
Repository-URI:http://www.example.com/voiceprints
Voiceprint-Identifier:johnsmith.voiceprint
S->C: MRCP/2.0 ... 314161 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
C->S: MRCP/2.0 ... VERIFY 314162
Channel-Identifier:32AECB23433801@speakverify
Ver-buffer-utterance:true
S->C: MRCP/2.0 ... 314162 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... VERIFICATION-COMPLETE 314162 COMPLETE Channel-Identifier:32AECB23433801@speakverify Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... VERIFICATION-COMPLETE 314162 COMPLETE Channel-Identifier：32AECB23433801 @ speakverify Completion-Cause：000 success Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="What-Grammar-URI">
<verification-result>
<voiceprint id="johnsmith">
<incremental>
<utterance-length> 500 </utterance-length>
<device> cellular-phone </device>
<gender> female </gender>
<decision> rejected </decision>
<verification-score> 0.05465 </verification-score>
</incremental>
<cumulative>
<utterance-length> 500 </utterance-length>
<device> cellular-phone </device>
<gender> female </gender>
<decision> rejected </decision>
<verification-score> 0.05465 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</result>
C->S: MRCP/2.0 ... QUERY-VOICEPRINT 314163
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/voiceprints/
Voiceprint-Identifier:johnsmith
S->C: MRCP/2.0 ... 314163 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
Repository-URI:http://www.example.com/voiceprints/
Voiceprint-Identifier:johnsmith.voiceprint
Voiceprint-Exists:true
C->S: MRCP/2.0 ... START-SESSION 314164
Channel-Identifier:32AECB23433801@speakverify
Verification-Mode:verify
Adapt-Model:true
Repository-URI:http://www.example.com/voiceprints
Voiceprint-Identifier:marysmith.voiceprint
S->C: MRCP/2.0 ... 314164 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
C->S: MRCP/2.0 ... VERIFY-FROM-BUFFER 314165
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 314165 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... VERIFICATION-COMPLETE 314165 COMPLETE Channel-Identifier:32AECB23433801@speakverify Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... VERIFICATION-COMPLETE 314165 COMPLETE Channel-Identifier：32AECB23433801 @ speakverify Completion-Cause：000 success Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="What-Grammar-URI">
<verification-result>
<voiceprint id="marysmith">
<incremental>
<utterance-length> 1000 </utterance-length>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.98 </verification-score>
</incremental>
<cumulative>
<utterance-length> 1000 </utterance-length>
<device> cellular-phone </device>
<gender> female </gender>
<decision> accepted </decision>
<verification-score> 0.98 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</result>
C->S: MRCP/2.0 ... END-SESSION 314166
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 314166 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
VERIFY-FROM-BUFFER Example
VERIFY-FROM-BUFFERの例
The VERIFY-ROLLBACK method discards the last buffered utterance or discards the last live utterances (when the mode is "train" or "verify"). The client will likely want to invoke this method when the user provides undesirable input such as non-speech noises, side-speech, out-of-grammar utterances, commands, etc. Note that this method does not provide a stack of rollback states. Executing VERIFY-ROLLBACK twice in succession without an intervening recognition operation has no effect on the second attempt.
VERIFY-ROLLBACKメソッドは、最後にバッファされた発話を破棄するか、最後のライブ発話を破棄します（モードが「train」または「verify」の場合）。ユーザーが音声以外のノイズ、副音声、文法外の発話、コマンドなどの望ましくない入力を提供した場合、クライアントはこのメソッドを呼び出す可能性があります。このメソッドはロールバック状態のスタックを提供しないことに注意してください。認識操作の介入なしにVERIFY-ROLLBACKを2回続けて実行しても、2回目の試行には影響がありません。
C->S: MRCP/2.0 ... VERIFY-ROLLBACK 314165
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 314165 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
VERIFY-ROLLBACK Example
VERIFY-ROLLBACKの例
The STOP method from the client to the server tells the verifier resource to stop the VERIFY or VERIFY-FROM-BUFFER request if one is active. If such a request is active and the STOP request successfully terminated it, then the response header section contains an Active-Request-Id-List header field containing the request-id of the VERIFY or VERIFY-FROM-BUFFER request that was terminated. In this case, no VERIFICATION-COMPLETE event is sent for the terminated request. If there was no verify request active, then the response MUST NOT contain an Active-Request-Id-List header field. Either way, the response MUST contain a status-code of 200 "Success".
クライアントからサーバーへのSTOPメソッドは、検証リソースに、VERIFYまたはVERIFY-FROM-BUFFER要求がアクティブな場合はそれを停止するように指示します。このような要求がアクティブで、STOP要求が正常に終了した場合、応答ヘッダーセクションには、終了したVERIFYまたはVERIFY-FROM-BUFFER要求のrequest-idを含むActive-Request-Id-Listヘッダーフィールドが含まれます。この場合、終了したリクエストに対してVERIFICATION-COMPLETEイベントは送信されません。検証要求がアクティブでなかった場合、応答にはActive-Request-Id-Listヘッダーフィールドを含めてはなりません（MUST NOT）。どちらの方法でも、応答には200 "成功"のステータスコードが含まれている必要があります。
The STOP method can carry an Abort-Verification header field, which specifies if the verification result until that point should be discarded or returned. If this header field is not present or if the value is "true", the verification result is discarded and the STOP response does not contain any result data. If the header field is present and its value is "false", the STOP response MUST contain a Completion-Cause header field and carry the Verification result data in its body.
STOPメソッドは、その時点までの検証結果を破棄するか返すかを指定するAbort-Verificationヘッダーフィールドを運ぶことができます。このヘッダーフィールドが存在しない場合、または値が「true」の場合、検証結果は破棄され、STOP応答には結果データが含まれません。ヘッダーフィールドが存在し、その値が「false」の場合、STOP応答はCompletion-Causeヘッダーフィールドを含み、検証結果データを本文に含める必要があります。
An aborted VERIFY request does an automatic rollback and hence does not affect the cumulative score. A VERIFY request that was stopped with no Abort-Verification header field or with the Abort-Verification header field set to "false" does affect cumulative scores and would need to be explicitly rolled back if the client does not want the verification result considered in the cumulative scores.
中止されたVERIFY要求は自動ロールバックを行うため、累積スコアには影響しません。 Abort-Verificationヘッダーフィールドなしで、またはAbort-Verificationヘッダーフィールドを "false"に設定して停止したVERIFYリクエストは累積スコアに影響し、クライアントが検証結果を考慮しない場合は明示的にロールバックする必要があります。累積スコア。
The following example assumes a voiceprint identity has already been established.
次の例では、声紋IDがすでに確立されていると想定しています。
C->S: MRCP/2.0 ... VERIFY 314177
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 314177 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speakverify
C->S: MRCP/2.0 ... STOP 314178
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 314178 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
Active-Request-Id-List:314177
STOP Verification Example
STOP検証の例
This request is sent from the client to the verifier resource to start the no-input timer, usually once the client has ascertained that any audio prompts to the user have played to completion.
このリクエストは、クライアントからベリファイアリソースに送信され、通常、クライアントがユーザーへの音声プロンプトの再生が完了したことを確認すると、無入力タイマーを開始します。
C->S: MRCP/2.0 ... START-INPUT-TIMERS 543260
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 543260 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
The VERIFICATION-COMPLETE event follows a call to VERIFY or VERIFY-FROM-BUFFER and is used to communicate the verification results to the client. The event message body contains only verification results.
VERIFICATION-COMPLETEイベントは、VERIFYまたはVERIFY-FROM-BUFFERへの呼び出しに続き、検証結果をクライアントに通知するために使用されます。イベントメッセージの本文には、検証結果のみが含まれます。
S->C: MRCP/2.0 ... VERIFICATION-COMPLETE 543259 COMPLETE Completion-Cause:000 success Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... VERIFICATION-COMPLETE 543259 COMPLETE Completion-Cause：000 success Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="What-Grammar-URI">
<verification-result>
<voiceprint id="johnsmith">
<incremental>
<utterance-length> 500 </utterance-length>
<device> cellular-phone </device>
<gender> male </gender>
<decision> accepted </decision>
<verification-score> 0.85 </verification-score>
</incremental>
<cumulative>
<utterance-length> 1500 </utterance-length>
<device> cellular-phone </device>
<gender> male </gender>
<decision> accepted </decision>
<verification-score> 0.75 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</result>
The START-OF-INPUT event is returned from the server to the client once the server has detected speech. This event is always returned by the verifier resource when speech has been detected, irrespective of whether or not the recognizer and verifier resources share the same session.
サーバーが音声を検出すると、START-OF-INPUTイベントがサーバーからクライアントに返されます。このイベントは、認識リソースと検証リソースが同じセッションを共有しているかどうかに関係なく、音声が検出されたときに常に検証リソースによって返されます。
S->C: MRCP/2.0 ... START-OF-INPUT 543259 IN-PROGRESS
Channel-Identifier:32AECB23433801@speakverify
The CLEAR-BUFFER method can be used to clear the verification buffer. This buffer is used to buffer speech during recognition, record, or verification operations that may later be used by VERIFY-FROM-BUFFER. As noted before, the buffer associated with the verifier resource is shared by other input resources like recognizers and recorders. Hence, a CLEAR-BUFFER request fails if the verification buffer is in use. This can happen when any one of the input resources that share this buffer has an active read or write operation such as RECORD, RECOGNIZE, or VERIFY with the Ver-Buffer-Utterance header field set to "true".
CLEAR-BUFFERメソッドを使用して、検証バッファーをクリアできます。このバッファは、後でVERIFY-FROM-BUFFERによって使用される可能性がある認識、記録、または検証操作中に音声をバッファするために使用されます。前述のように、ベリファイアリソースに関連付けられたバッファは、レコグナイザやレコーダなどの他の入力リソースによって共有されます。したがって、検証バッファーが使用中の場合、CLEAR-BUFFER要求は失敗します。これは、このバッファーを共有する入力リソースのいずれかに、REC-、RECOGNIZE、VERIFYなどのアクティブな読み取りまたは書き込み操作があり、Ver-Buffer-Utteranceヘッダーフィールドが「true」に設定されている場合に発生する可能性があります。
C->S: MRCP/2.0 ... CLEAR-BUFFER 543260
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 543260 200 COMPLETE
Channel-Identifier:32AECB23433801@speakverify
A client can use the GET-INTERMEDIATE-RESULT method to poll for intermediate results of a verification request that is in progress. Invoking this method does not change the state of the resource. The verifier resource collects the accumulated verification results and returns the information in the method response. The message body in the response to a GET-INTERMEDIATE-RESULT REQUEST contains only verification results. The method response MUST NOT contain a Completion-Cause header field as the request is not yet complete. If the resource does not have a verification in progress, the response has a 402 failure status-code and no result in the body.
クライアントは、GET-INTERMEDIATE-RESULTメソッドを使用して、進行中の検証要求の中間結果をポーリングできます。このメソッドを呼び出しても、リソースの状態は変更されません。検証リソースは、累積された検証結果を収集し、メソッド応答で情報を返します。 GET-INTERMEDIATE-RESULT REQUESTへの応答のメッセージ本文には、検証結果のみが含まれます。メソッドの応答には、リクエストがまだ完了していないため、Completion-Causeヘッダーフィールドを含めてはなりません（MUST NOT）。リソースの検証が進行中でない場合、レスポンスの402ステータスコードは失敗し、本文には結果がありません。
C->S: MRCP/2.0 ... GET-INTERMEDIATE-RESULT 543260
Channel-Identifier:32AECB23433801@speakverify
S->C: MRCP/2.0 ... 543260 200 COMPLETE Channel-Identifier:32AECB23433801@speakverify Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... 543260 200 COMPLETE Channel-Identifier：32AECB23433801 @ speakverify Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
grammar="What-Grammar-URI">
<verification-result>
<voiceprint id="marysmith">
<incremental>
<utterance-length> 50 </utterance-length>
<device> cellular-phone </device>
<gender> female </gender>
<decision> undecided </decision>
<verification-score> 0.85 </verification-score>
</incremental>
<cumulative>
<utterance-length> 150 </utterance-length>
<device> cellular-phone </device>
<gender> female </gender>
<decision> undecided </decision>
<verification-score> 0.65 </verification-score>
</cumulative>
</voiceprint>
</verification-result>
</result>
MRCPv2 is designed to comply with the security-related requirements documented in the SPEECHSC requirements [RFC4313]. Implementers and users of MRCPv2 are strongly encouraged to read the Security Considerations section of [RFC4313], because that document contains discussion of a number of important security issues associated with the utilization of speech as biometric authentication technology, and on the threats against systems which store recorded speech, contain large corpora of voiceprints, and send and receive sensitive information based on voice input to a recognizer or speech output from a synthesizer. Specific security measures employed by MRCPv2 are summarized in the following subsections. See the corresponding sections of this specification for how the security-related machinery is invoked by individual protocol operations.
MRCPv2は、SPEECHSC要件[RFC4313]で文書化されているセキュリティ関連の要件に準拠するように設計されています。 MRCPv2の実装者とユーザーは、[RFC4313]のセキュリティに関する考慮事項のセクションを読むことを強くお勧めします。そのドキュメントには、生体認証技術としての音声の利用に関連する多くの重要なセキュリティ問題と、保存するシステムに対する脅威に関する議論が含まれているためです録音された音声、声紋の大規模なコーパスを含み、認識装置への音声入力またはシンセサイザからの音声出力に基づいて機密情報を送受信します。 MRCPv2で採用されている特定のセキュリティ対策は、次のサブセクションにまとめられています。セキュリティ関連の機構が個々のプロトコル操作によってどのように呼び出されるかについては、この仕様の対応するセクションを参照してください。
MRCPv2 control sessions are established as media sessions described by SDP within the context of a SIP dialog. In order to ensure secure rendezvous between MRCPv2 clients and servers, the following are required:
MRCPv2制御セッションは、SIPダイアログのコンテキスト内でSDPによって記述されるメディアセッションとして確立されます。 MRCPv2クライアントとサーバー間の安全なランデブーを保証するために、以下が必要です。
1. The SIP implementation in MRCPv2 clients and servers MUST support SIP digest authentication [RFC3261] and SHOULD employ it.
1. MRCPv2クライアントおよびサーバーのSIP実装は、SIPダイジェスト認証[RFC3261]をサポートしなければならず（MUST）、それを採用する必要があります（SHOULD）。
2. The SIP implementation in MRCPv2 clients and servers MUST support 'sips' URIs and SHOULD employ 'sips' URIs; this includes that clients and servers SHOULD set up TLS [RFC5246] connections.
2. MRCPv2クライアントおよびサーバーのSIP実装は「sips」URIをサポートする必要があり、「sips」URIを使用する必要があります。これには、クライアントとサーバーがTLS [RFC5246]接続をセットアップする必要があることが含まれます。
3. If media stream cryptographic keying is done through SDP (e.g. using [RFC4568]), the MRCPv2 clients and servers MUST employ the 'sips' URI.
3. メディアストリームの暗号化キーがSDPを介して行われる場合（[RFC4568]を使用するなど）、MRCPv2クライアントとサーバーは「sips」URIを使用する必要があります。
4. When TLS is used for SIP, the client MUST verify the identity of the server to which it connects, following the rules and guidelines defined in [RFC5922].
4. SIPにTLSを使用する場合、クライアントは、[RFC5922]で定義されているルールとガイドラインに従って、接続先のサーバーのIDを検証する必要があります。
Sensitive data is carried over the MRCPv2 control channel. This includes things like the output of speech recognition operations, speaker verification results, input to text-to-speech conversion, personally identifying grammars, etc. For this reason, MRCPv2 servers must be properly authenticated, and the control channel must permit the use of both confidentiality and integrity for the data. To ensure control channel protection, MRCPv2 clients and servers MUST support TLS and SHOULD utilize it by default unless alternative control channel protection is used. When TLS is used, the client MUST verify the identity of the server to which it connects, following the rules and guidelines defined in [RFC4572]. If there are multiple TLS-protected channels between the client and the server, the server MUST NOT send a response to the client over a channel for which the TLS identities of the server or client differ from the channel over which the server received the corresponding request. Alternative control-channel protection MAY be used if desired (e.g., Security Architecture for the Internet Protocol (IPsec) [RFC4301]).
機密データはMRCPv2制御チャネルを介して伝送されます。これには、音声認識操作の出力、話者の検証結果、テキストから音声への変換への入力、個人を特定する文法などが含まれます。このため、MRCPv2サーバーは適切に認証され、コントロールチャネルは、データの機密性と整合性の両方。制御チャネル保護を確実にするために、MRCPv2クライアントとサーバーはTLSをサポートする必要があり、代替の制御チャネル保護が使用されない限り、デフォルトでそれを利用する必要があります（SHOULD）。 TLSを使用する場合、クライアントは、[RFC4572]で定義されているルールとガイドラインに従って、接続先のサーバーのIDを検証する必要があります。クライアントとサーバーの間にTLSで保護されたチャネルが複数ある場合、サーバーは、サーバーまたはクライアントのTLS IDがサーバーが対応する要求を受信したチャネルとは異なるチャネルを介してクライアントに応答を送信してはなりません（MUST NOT）。 。必要に応じて、代替の制御チャネル保護を使用してもよい（たとえば、インターネットプロトコル（IPsec）のセキュリティアーキテクチャ[RFC4301]）。
Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. One such mechanism is the Secure Real-time Transport Protocol (SRTP) [RFC3711].
機密データは、MRCPv2サーバーで終了するメディアセッションでも伝送されます（メディアチャネルのもう一方の端は、MRCPv2クライアント上にある場合とない場合があります）。このデータには、ユーザーの発話と、音声合成操作の出力が含まれます。 MRCPv2サーバーは、オーディオメディアセッションを保護するためのセキュリティメカニズムをサポートする必要があります。同様にオーディオを発信または消費するMRCPv2クライアントは、オーディオを保護するためのセキュリティメカニズムをサポートする必要があります。そのようなメカニズムの1つは、Secure Real-time Transport Protocol（SRTP）[RFC3711]です。
MCRPv2 employs content indirection extensively. Content may be fetched and/or stored based on URI addressing on systems other than the MRCPv2 client or server. Not all of the stored content is necessarily sensitive (e.g., XML schemas), but the majority generally needs protection, and some indirect content, such as voice recordings and voiceprints, is extremely sensitive and must always be protected. MRCPv2 clients and servers MUST implement HTTPS for indirect content access and SHOULD employ secure access for all sensitive indirect content. Other secure URI schemes such as Secure FTP (FTPS) [RFC4217] MAY also be used. See Section 6.2.15 for the header fields used to transfer cookie information between the MRCPv2 client and server if needed for authentication.
MCRPv2は、コンテンツの間接参照を広範囲に採用しています。コンテンツは、MRCPv2クライアントまたはサーバー以外のシステムのURIアドレッシングに基づいてフェッチまたは保存されます。保存されているすべてのコンテンツが機密である必要はありません（XMLスキーマなど）。ただし、大多数は一般に保護が必要です。また、音声録音や声紋などの一部の間接コンテンツは非常に機密であり、常に保護する必要があります。 MRCPv2クライアントとサーバーは、間接的なコンテンツアクセスのためにHTTPSを実装する必要があり、すべての機密性の高い間接的なコンテンツに対して安全なアクセスを採用する必要があります。セキュアFTP（FTPS）[RFC4217]などの他のセキュアURIスキームも使用できます（MAY）。認証に必要な場合にMRCPv2クライアントとサーバー間でCookie情報を転送するために使用されるヘッダーフィールドについては、セクション6.2.15を参照してください。
Access to URIs provided by servers introduces risks that need to be considered. Although RFC 6454 [RFC6454] discusses and focuses on a same-origin policy, which MRCPv2 does not restrict URIs to, it still provides an excellent description of the pitfalls of blindly following server-provided URIs in Section 3 of the RFC. Servers also need to be aware that clients could provide URIs to sites designed to tie up the server in long or otherwise problematic document fetches. MRCPv2 servers, and the services they access, MUST always be prepared for the possibility of such a denial-of-service attack.
サーバーによって提供されるURIへのアクセスは、考慮する必要があるリスクをもたらします。 RFC 6454 [RFC6454]は、MRCPv2がURIを制限しない同一生成元ポリシーについて説明および焦点を当てていますが、RFCのセクション3でサーバー提供のURIを盲目的にフォローすることの落とし穴に関する優れた説明を提供しています。サーバーは、クライアントが長い間、または問題のあるドキュメントのフェッチでサーバーを拘束するように設計されたサイトにURIを提供できることにも注意する必要があります。 MRCPv2サーバーとそのサーバーがアクセスするサービスは、このようなサービス拒否攻撃の可能性に常に備える必要があります。
MRCPv2 makes no inherent assumptions about the lifetime and access controls associated with a URI. For example, if neither authentication nor scheme-specific access controls are used, a leak of the URI is equivalent to a leak of the content. Moreover, MRCPv2 makes no specific demands on the lifetime of a URI. If a server offers a URI and the client takes a long, long time to access that URI, the server may have removed the resource in the interim time period. MRCPv2 deals with this case by using the URI access scheme's 'resource not found' error, such as 404 for HTTPS. How long a server should keep a dynamic resource available is highly application and context dependent. However, the server SHOULD keep the resource available for a reasonable amount of time to make it likely the client will have the resource available when the client needs the resource. Conversely, to mitigate state exhaustion attacks, MRCPv2 servers are not obligated to keep resources and resource state in perpetuity. The server SHOULD delete dynamically generated resources associated with an MRCPv2 session when the session ends.
MRCPv2は、URIに関連付けられた有効期間とアクセス制御について固有の仮定を行いません。たとえば、認証もスキーム固有のアクセス制御も使用されていない場合、URIの漏洩はコンテンツの漏洩と同等です。さらに、MRCPv2は、URIの存続期間について特定の要求を行いません。サーバーがURIを提供し、クライアントがそのURIにアクセスするのに長い時間がかかる場合、サーバーはその間にリソースを削除した可能性があります。 MRCPv2は、HTTPSの404など、URIアクセススキームの「リソースが見つかりません」エラーを使用してこのケースを処理します。サーバーが動的リソースを使用可能に保つ期間は、アプリケーションとコンテキストに大きく依存します。ただし、サーバーは、クライアントがリソースを必要とするときにクライアントがリソースを利用できるようにするために、妥当な時間リソースを利用できるようにする必要があります（SHOULD）。逆に、状態枯渇攻撃を緩和するために、MRCPv2サーバーはリソースとリソースの状態を永続的に保つ義務はありません。サーバーは、セッションが終了すると、MRCPv2セッションに関連付けられた動的に生成されたリソースを削除する必要があります（SHOULD）。
One method to avoid resource leakage is for the server to use difficult-to-guess, one-time resource URIs. In this instance, there can be only a single access to the underlying resource using the given URI. A downside to this approach is if an attacker uses the URI before the client uses the URI, then the client is denied the resource. Other methods would be to adopt a mechanism similar to the URLAUTH IMAP extension [RFC4467], where the server sets cryptographic checks on URI usage, as well as capabilities for expiration, revocation, and so on. Specifying such a mechanism is beyond the scope of this document.
リソースリークを回避する1つの方法は、サーバーが推測が困難な1回限りのリソースURIを使用することです。この場合、特定のURIを使用して、基になるリソースへのアクセスは1つだけです。このアプローチの欠点は、クライアントがURIを使用する前に攻撃者がURIを使用した場合、クライアントはリソースを拒否されることです。他の方法は、URLAUTH IMAP拡張[RFC4467]と同様のメカニズムを採用することです。サーバーは、URIの使用に関する暗号チェックと、有効期限、失効などの機能を設定します。このようなメカニズムの指定は、このドキュメントの範囲外です。
MRCPv2 applications often require the use of stored media. Voice recordings are both stored (e.g., for diagnosis and system tuning), and fetched (for replaying utterances into multiple MRCPv2 resources). Voiceprints are fundamental to the speaker identification and verification functions. This data can be extremely sensitive and can present substantial privacy and impersonation risks if stolen. Systems employing MRCPv2 SHOULD be deployed in ways that minimize these risks. The SPEECHSC requirements RFC [RFC4313] contains a more extensive discussion of these risks and ways they may be mitigated.
MRCPv2アプリケーションでは、多くの場合、保存されたメディアを使用する必要があります。音声録音は、両方とも保存され（診断やシステム調整など）、フェッチされます（発話を複数のMRCPv2リソースに再生するため）。声紋は、話者の識別および検証機能の基本です。このデータは非常に機密である可能性があり、盗まれた場合、プライバシーとなりすましのリスクが高まる可能性があります。 MRCPv2を採用するシステムは、これらのリスクを最小限に抑える方法で展開する必要があります。 SPEECHSC要件RFC [RFC4313]には、これらのリスクとそれらを軽減する方法に関するより広範な議論が含まれています。
DTMF buffers and recognition buffers may grow large enough to exceed the capabilities of a server, and the server MUST be prepared to gracefully handle resource consumption. A server MAY respond with the appropriate recognition incomplete if the server is in danger of running out of resources.
DTMFバッファーと認識バッファーは、サーバーの機能を超えるほど大きくなる可能性があり、サーバーはリソース消費を適切に処理できるように準備する必要があります。サーバーがリソース不足になる危険がある場合、サーバーは適切な認識が不完全で応答してもよい（MAY）。
In MRCPv2, there are some tasks, such as URI resource fetches, that the server does on behalf of the client. To control this behavior, MRCPv2 has a number of server parameters that a client can configure. With one such parameter, Fetch-Timeout (Section 6.2.12), a malicious client could set a very large value and then request the server to fetch a non-existent document. It is RECOMMENDED that servers be cautious about accepting long timeout values or abnormally large values for other client-set parameters.
MRCPv2には、URIリソースのフェッチなど、サーバーがクライアントに代わって行ういくつかのタスクがあります。この動作を制御するために、MRCPv2にはクライアントが構成できる多数のサーバーパラメーターがあります。このようなパラメーターの1つであるFetch-Timeout（セクション6.2.12）を使用すると、悪意のあるクライアントが非常に大きな値を設定し、存在しないドキュメントをフェッチするようサーバーに要求する可能性があります。サーバーは、長いタイムアウト値や他のクライアントセットパラメータの異常に大きな値を受け入れることに注意することをお勧めします。
Since this specification does not mandate a specific mechanism for authentication and authorization when requesting DELETE-VOICEPRINT (Section 11.9), there is a risk that an MRCPv2 server may not do such a check for authentication and authorization. In practice, each provider of voice biometric solutions does insist on its own authentication and authorization mechanism, outside of this specification, so this is not likely to be a major problem. If in the future voice biometric providers standardize on such a mechanism, then a future version of MRCP can mandate it.
この仕様では、DELETE-VOICEPRINT（セクション11.9）を要求するときに認証と承認の特定のメカニズムを義務付けていないため、MRCPv2サーバーが認証と承認のそのようなチェックを行わない可能性があります。実際には、音声生体認証ソリューションの各プロバイダーは、この仕様外の独自の認証および承認メカニズムを主張しているため、これは大きな問題にはなりません。将来、音声生体認証プロバイダーがそのようなメカニズムで標準化する場合、MRCPの将来のバージョンでそれを義務付けることができます。
This section describes the name spaces (registries) for MRCPv2 that IANA has created and now maintains. Assignment/registration policies are described in RFC 5226 [RFC5226].
このセクションでは、IANAが作成し、現在維持しているMRCPv2の名前空間（レジストリ）について説明します。割り当て/登録ポリシーは、RFC 5226 [RFC5226]で説明されています。
IANA has created a new name space of "MRCPv2 Resource Types". All
maintenance within and additions to the contents of this name space
MUST be according to the "Standards Action" registration policy. The
initial contents of the registry, defined in Section 4.2, are given
below:
Resource type Resource description Reference
------------- -------------------- ---------
speechrecog Speech Recognizer [RFC6787]
dtmfrecog DTMF Recognizer [RFC6787]
speechsynth Speech Synthesizer [RFC6787]
basicsynth Basic Synthesizer [RFC6787]
speakverify Speaker Verifier [RFC6787]
recorder Speech Recorder [RFC6787]
IANA has created a new name space of "MRCPv2 Methods and Events". All maintenance within and additions to the contents of this name space MUST be according to the "Standards Action" registration policy. The initial contents of the registry, defined by the "method-name" and "event-name" BNF in Section 15 and explained in Sections 5.2 and 5.5, are given below.
IANAは「MRCPv2メソッドとイベント」の新しい名前空間を作成しました。この名前空間内のすべてのメンテナンスとその内容への追加は、「標準アクション」登録ポリシーに従う必要があります。セクション15で「method-name」および「event-name」BNFによって定義され、セクション5.2および5.5で説明されているレジストリの初期内容を以下に示します。
Name Resource type Method/Event Reference
---- ------------- ------------ ---------
SET-PARAMS Generic Method [RFC6787]
GET-PARAMS Generic Method [RFC6787]
SPEAK Synthesizer Method [RFC6787]
STOP Synthesizer Method [RFC6787]
PAUSE Synthesizer Method [RFC6787]
RESUME Synthesizer Method [RFC6787]
BARGE-IN-OCCURRED Synthesizer Method [RFC6787]
CONTROL Synthesizer Method [RFC6787]
DEFINE-LEXICON Synthesizer Method [RFC6787]
DEFINE-GRAMMAR Recognizer Method [RFC6787]
RECOGNIZE Recognizer Method [RFC6787]
INTERPRET Recognizer Method [RFC6787]
GET-RESULT Recognizer Method [RFC6787]
START-INPUT-TIMERS Recognizer Method [RFC6787]
STOP Recognizer Method [RFC6787]
START-PHRASE-ENROLLMENT Recognizer Method [RFC6787]
ENROLLMENT-ROLLBACK Recognizer Method [RFC6787]
END-PHRASE-ENROLLMENT Recognizer Method [RFC6787]
MODIFY-PHRASE Recognizer Method [RFC6787]
DELETE-PHRASE Recognizer Method [RFC6787]
RECORD Recorder Method [RFC6787]
STOP Recorder Method [RFC6787]
START-INPUT-TIMERS Recorder Method [RFC6787]
START-SESSION Verifier Method [RFC6787]
END-SESSION Verifier Method [RFC6787]
QUERY-VOICEPRINT Verifier Method [RFC6787]
DELETE-VOICEPRINT Verifier Method [RFC6787]
VERIFY Verifier Method [RFC6787]
VERIFY-FROM-BUFFER Verifier Method [RFC6787]
VERIFY-ROLLBACK Verifier Method [RFC6787]
STOP Verifier Method [RFC6787]
START-INPUT-TIMERS Verifier Method [RFC6787]
GET-INTERMEDIATE-RESULT Verifier Method [RFC6787]
SPEECH-MARKER Synthesizer Event [RFC6787]
SPEAK-COMPLETE Synthesizer Event [RFC6787]
START-OF-INPUT Recognizer Event [RFC6787]
RECOGNITION-COMPLETE Recognizer Event [RFC6787]
INTERPRETATION-COMPLETE Recognizer Event [RFC6787]
START-OF-INPUT Recorder Event [RFC6787]
RECORD-COMPLETE Recorder Event [RFC6787]
VERIFICATION-COMPLETE Verifier Event [RFC6787]
START-OF-INPUT Verifier Event [RFC6787]
IANA has created a new name space of "MRCPv2 Header Fields". All maintenance within and additions to the contents of this name space MUST be according to the "Standards Action" registration policy. The initial contents of the registry, defined by the "message-header" BNF in Section 15 and explained in Section 5.1, are given below. Note that the values permitted for the "Vendor-Specific-Parameters" parameter are managed according to a different policy. See Section 13.1.6.
IANAは「MRCPv2ヘッダーフィールド」の新しい名前空間を作成しました。この名前空間内のすべてのメンテナンスとその内容への追加は、「標準アクション」登録ポリシーに従う必要があります。セクション15で「メッセージヘッダー」BNFによって定義され、セクション5.1で説明されているレジストリの初期内容を以下に示します。 「Vendor-Specific-Parameters」パラメーターに許可される値は、別のポリシーに従って管理されることに注意してください。セクション13.1.6を参照してください。
Name Resource type Reference
---- ------------- ---------
Channel-Identifier Generic [RFC6787]
Accept Generic [RFC2616]
Active-Request-Id-List Generic [RFC6787]
Proxy-Sync-Id Generic [RFC6787]
Accept-Charset Generic [RFC2616]
Content-Type Generic [RFC6787]
Content-ID Generic
[RFC2392], [RFC2046], and [RFC5322]
Content-Base Generic [RFC6787]
Content-Encoding Generic [RFC6787]
Content-Location Generic [RFC6787]
Content-Length Generic [RFC6787]
Fetch-Timeout Generic [RFC6787]
Cache-Control Generic [RFC6787]
Logging-Tag Generic [RFC6787]
Set-Cookie Generic [RFC6787]
Vendor-Specific Generic [RFC6787]
Jump-Size Synthesizer [RFC6787]
Kill-On-Barge-In Synthesizer [RFC6787]
Speaker-Profile Synthesizer [RFC6787]
Completion-Cause Synthesizer [RFC6787]
Completion-Reason Synthesizer [RFC6787]
Voice-Parameter Synthesizer [RFC6787]
Prosody-Parameter Synthesizer [RFC6787]
Speech-Marker Synthesizer [RFC6787]
Speech-Language Synthesizer [RFC6787]
Fetch-Hint Synthesizer [RFC6787]
Audio-Fetch-Hint Synthesizer [RFC6787]
Failed-URI Synthesizer [RFC6787]
Failed-URI-Cause Synthesizer [RFC6787]
Speak-Restart Synthesizer [RFC6787]
Speak-Length Synthesizer [RFC6787]
Load-Lexicon Synthesizer [RFC6787]
Lexicon-Search-Order Synthesizer [RFC6787]
Confidence-Threshold Recognizer [RFC6787]
Sensitivity-Level Recognizer [RFC6787]
Speed-Vs-Accuracy Recognizer [RFC6787]
N-Best-List-Length Recognizer [RFC6787]
Input-Type Recognizer [RFC6787]
No-Input-Timeout Recognizer [RFC6787]
Recognition-Timeout Recognizer [RFC6787]
Waveform-URI Recognizer [RFC6787]
Input-Waveform-URI Recognizer [RFC6787]
Completion-Cause Recognizer [RFC6787]
Completion-Reason Recognizer [RFC6787]
Recognizer-Context-Block Recognizer [RFC6787]
Start-Input-Timers Recognizer [RFC6787]
Speech-Complete-Timeout Recognizer [RFC6787]
Speech-Incomplete-Timeout Recognizer [RFC6787]
Dtmf-Interdigit-Timeout Recognizer [RFC6787]
Dtmf-Term-Timeout Recognizer [RFC6787]
Dtmf-Term-Char Recognizer [RFC6787]
Failed-URI Recognizer [RFC6787]
Failed-URI-Cause Recognizer [RFC6787]
Save-Waveform Recognizer [RFC6787]
Media-Type Recognizer [RFC6787]
New-Audio-Channel Recognizer [RFC6787]
Speech-Language Recognizer [RFC6787]
Ver-Buffer-Utterance Recognizer [RFC6787]
Recognition-Mode Recognizer [RFC6787]
Cancel-If-Queue Recognizer [RFC6787]
Hotword-Max-Duration Recognizer [RFC6787]
Hotword-Min-Duration Recognizer [RFC6787]
Interpret-Text Recognizer [RFC6787]
Dtmf-Buffer-Time Recognizer [RFC6787]
Clear-Dtmf-Buffer Recognizer [RFC6787]
Early-No-Match Recognizer [RFC6787]
Num-Min-Consistent-Pronunciations Recognizer [RFC6787]
Consistency-Threshold Recognizer [RFC6787]
Clash-Threshold Recognizer [RFC6787]
Personal-Grammar-URI Recognizer [RFC6787]
Enroll-Utterance Recognizer [RFC6787]
Phrase-ID Recognizer [RFC6787]
Phrase-NL Recognizer [RFC6787]
Weight Recognizer [RFC6787]
Save-Best-Waveform Recognizer [RFC6787]
New-Phrase-ID Recognizer [RFC6787]
Confusable-Phrases-URI Recognizer [RFC6787]
Abort-Phrase-Enrollment Recognizer [RFC6787]
Sensitivity-Level Recorder [RFC6787]
No-Input-Timeout Recorder [RFC6787]
Completion-Cause Recorder [RFC6787]
Completion-Reason Recorder [RFC6787]
Failed-URI Recorder [RFC6787]
Failed-URI-Cause Recorder [RFC6787]
Record-URI Recorder [RFC6787]
Media-Type Recorder [RFC6787]
Max-Time Recorder [RFC6787]
Trim-Length Recorder [RFC6787]
Final-Silence Recorder [RFC6787]
Capture-On-Speech Recorder [RFC6787]
Ver-Buffer-Utterance Recorder [RFC6787]
Start-Input-Timers Recorder [RFC6787]
New-Audio-Channel Recorder [RFC6787]
Repository-URI Verifier [RFC6787]
Voiceprint-Identifier Verifier [RFC6787]
Verification-Mode Verifier [RFC6787]
Adapt-Model Verifier [RFC6787]
Abort-Model Verifier [RFC6787]
Min-Verification-Score Verifier [RFC6787]
Num-Min-Verification-Phrases Verifier [RFC6787]
Num-Max-Verification-Phrases Verifier [RFC6787]
No-Input-Timeout Verifier [RFC6787]
Save-Waveform Verifier [RFC6787]
Media-Type Verifier [RFC6787]
Waveform-URI Verifier [RFC6787]
Voiceprint-Exists Verifier [RFC6787]
Ver-Buffer-Utterance Verifier [RFC6787]
Input-Waveform-URI Verifier [RFC6787]
Completion-Cause Verifier [RFC6787]
Completion-Reason Verifier [RFC6787]
Speech-Complete-Timeout Verifier [RFC6787]
New-Audio-Channel Verifier [RFC6787]
Abort-Verification Verifier [RFC6787]
Start-Input-Timers Verifier [RFC6787]
Input-Type Verifier [RFC6787]
IANA has created a new name space of "MRCPv2 Status Codes" with the initial values that are defined in Section 5.4. All maintenance within and additions to the contents of this name space MUST be according to the "Specification Required with Expert Review" registration policy.
IANAは、「MRCPv2ステータスコード」の新しい名前空間を作成しました。初期値はセクション5.4で定義されています。この名前空間内のすべてのメンテナンスとその内容への追加は、「エキスパートレビューで必要な仕様」登録ポリシーに従っている必要があります。
IANA has created a new name space of "Grammar Reference List Parameters". All maintenance within and additions to the contents of this name space MUST be according to the "Specification Required with Expert Review" registration policy. There is only one initial parameter as shown below.
IANAは、「Grammar Reference List Parameters」という新しい名前空間を作成しました。この名前空間内のすべてのメンテナンスとその内容への追加は、「エキスパートレビューで必要な仕様」登録ポリシーに従っている必要があります。以下に示すように、初期パラメーターは1つだけです。
Name Reference
---- -------------
weight [RFC6787]
IANA has created a new name space of "MRCPv2 Vendor-Specific Parameters". All maintenance within and additions to the contents of this name space MUST be according to the "Hierarchical Allocation" registration policy as follows. Each name (corresponding to the "vendor-av-pair-name" ABNF production) MUST satisfy the syntax requirements of Internet Domain Names as described in Section 2.3.1 of RFC 1035 [RFC1035] (and as updated or obsoleted by successive RFCs), with one exception, the order of the domain names is reversed. For example, a vendor-specific parameter "foo" by example.com would have the form "com.example.foo". The first, or top-level domain, is restricted to exactly the set of Top-Level Internet Domains defined by IANA and will be updated by IANA when and only when that set changes. The second-level and all subdomains within the parameter name MUST be allocated according to the "First Come First Served" policy. It is RECOMMENDED that assignment requests adhere to the existing allocations of Internet domain names to organizations, institutions, corporations, etc.
IANAは「MRCPv2 Vendor-Specific Parameters」の新しい名前空間を作成しました。この名前空間内のすべてのメンテナンスと、この名前空間の内容への追加は、次のような「階層割り当て」登録ポリシーに従っている必要があります。各名前（「vendor-av-pair-name」ABNFプロダクションに対応）は、RFC 1035 [RFC1035]のセクション2.3.1（および後続のRFCによって更新または廃止）に記載されているインターネットドメイン名の構文要件を満たす必要があります。 、1つの例外を除き、ドメイン名の順序は逆になります。たとえば、example.comによるベンダー固有のパラメータ「foo」は、「com.example.foo」の形式になります。最初の、つまりトップレベルドメインは、IANAによって定義されたトップレベルインターネットドメインのセットに厳密に制限されており、そのセットが変更されたときにのみ、IANAによって更新されます。パラメータ名内の第2レベルとすべてのサブドメインは、「先着順」ポリシーに従って割り当てられる必要があります。割り当てリクエストは、組織、機関、企業などへのインターネットドメイン名の既存の割り当てに準拠することをお勧めします。
The registry contains a list of vendor-registered parameters, where each defined parameter is associated with a contact person and includes an optional reference to the definition of the parameter, preferably an RFC. The registry is initially empty.
レジストリには、ベンダーが登録したパラメーターのリストが含まれています。定義された各パラメーターは担当者に関連付けられており、パラメーターの定義へのオプションの参照（できればRFC）が含まれています。レジストリは最初は空です。
IANA has registered the following media type according to the process defined in RFC 4288 [RFC4288].
IANAは、RFC 4288 [RFC4288]で定義されているプロセスに従って、次のメディアタイプを登録しています。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type application/nlsml+xml
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: nlsml+xml
MIMEサブタイプ名：nlsml + xml
Required parameters: none
必須パラメーター：なし
Optional parameters:
オプションのパラメーター：
charset: All of the considerations described in RFC 3023 [RFC3023] also apply to the application/nlsml+xml media type.
charset：RFC 3023 [RFC3023]で説明されているすべての考慮事項は、application / nlsml + xmlメディアタイプにも適用されます。
Encoding considerations: All of the considerations described in RFC 3023 also apply to the 'application/nlsml+xml' media type.
エンコーディングに関する考慮事項：RFC 3023で説明されているすべての考慮事項は、「application / nlsml + xml」メディアタイプにも適用されます。
Security considerations: As with HTML, NLSML documents contain links to other data stores (grammars, verifier resources, etc.). Unlike HTML, however, the data stores are not treated as media to be rendered. Nevertheless, linked files may themselves have security considerations, which would be those of the individual registered types. Additionally, this media type has all of the security considerations described in RFC 3023.
セキュリティに関する考慮事項：HTMLと同様に、NLSMLドキュメントには他のデータストア（文法、検証リソースなど）へのリンクが含まれています。ただし、HTMLとは異なり、データストアはレンダリングされるメディアとして扱われません。それでも、リンクされたファイル自体にセキュリティ上の考慮事項がある場合があります。これは、個別に登録されたタイプのものと同じです。さらに、このメディアタイプには、RFC 3023で説明されているすべてのセキュリティに関する考慮事項があります。
Interoperability considerations: Although an NLSML document is itself a complete XML document, for a fuller interpretation of the content a receiver of an NLSML document may wish to access resources linked to by the document. The inability of an NLSML processor to access or process such linked resources could result in different behavior by the ultimate consumer of the data.
相互運用性に関する考慮事項：NLSMLドキュメントはそれ自体が完全なXMLドキュメントですが、コンテンツをより完全に解釈するために、NLSMLドキュメントの受信者は、ドキュメントによってリンクされているリソースにアクセスする必要があります。 NLSMLプロセッサーがこのようなリンクされたリソースにアクセスまたは処理できないと、データの最終的な消費者によって異なる動作が発生する可能性があります。
Published specification: RFC 6787
公開された仕様：RFC 6787
Applications that use this media type: MRCPv2 clients and servers
このメディアタイプを使用するアプリケーション：MRCPv2クライアントおよびサーバー
Additional information: none
追加情報：なし
Magic number(s): There is no single initial octet sequence that is always present for NLSML files.
マジックナンバー：NLSMLファイルに常に存在する単一の最初のオクテットシーケンスはありません。
Person & email address to contact for further information: Sarvi Shanmugham, sarvi@cisco.com
詳細について連絡する人とメールアドレス：Sarvi Shanmugham、sarvi @ cisco.com
Intended usage: This media type is expected to be used only in conjunction with MRCPv2.
使用目的：このメディアタイプは、MRCPv2との組み合わせでのみ使用することが想定されています。
IANA has registered and now maintains the following XML Schema. Information provided follows the template in RFC 3688 [RFC3688].
IANAは以下のXMLスキーマを登録し、現在維持しています。提供される情報は、RFC 3688 [RFC3688]のテンプレートに従います。
XML element type: schema
XML要素タイプ：スキーマ
URI: urn:ietf:params:xml:schema:nlsml
Registrant Contact: IESG
登録者の連絡先：IESG
XML: See Section 16.1.
XML：セクション16.1を参照してください。
IANA has registered and now maintains the following XML Name space. Information provided follows the template in RFC 3688 [RFC3688].
IANAは以下のXML名前空間を登録し、現在維持しています。提供される情報は、RFC 3688 [RFC3688]のテンプレートに従います。
XML element type: ns
XML要素タイプ：ns
URI: urn:ietf:params:xml:ns:mrcpv2
Registrant Contact: IESG
登録者の連絡先：IESG
XML: RFC 6787
ＸＭＬ： ＲＦＣ ６７８７
IANA has registered the following text media type according to the process defined in RFC 4288 [RFC4288].
IANAは、RFC 4288 [RFC4288]で定義されているプロセスに従って、次のテキストメディアタイプを登録しています。
To: ietf-types@iana.org
と： いえｔｆーｔｙぺｓ＠いあな。おｒｇ
Subject: Registration of media type text/grammar-ref-list
件名：メディアタイプtext / grammar-ref-listの登録
MIME media type name: text
MIMEメディアタイプ名：テキスト
MIME subtype name: text/grammar-ref-list
MIMEサブタイプ名：text / grammar-ref-list
Required parameters: none Optional parameters: none
必須パラメーター：なしオプションパラメーター：なし
Encoding considerations: Depending on the transfer protocol, a transfer encoding may be necessary to deal with very long lines.
エンコードに関する考慮事項：転送プロトコルによっては、非常に長い回線を処理するために転送エンコードが必要になる場合があります。
Security considerations: This media type contains URIs that may represent references to external resources. As these resources are assumed to be speech recognition grammars, similar considerations as for the media types 'application/srgs' and 'application/srgs+xml' apply.
セキュリティに関する考慮事項：このメディアタイプには、外部リソースへの参照を表すURIが含まれています。これらのリソースは音声認識文法であると想定されているため、メディアタイプ「application / srgs」および「application / srgs + xml」と同様の考慮事項が適用されます。
Interoperability considerations: '>' must be percent encoded in URIs according to RFC 3986 [RFC3986].
相互運用性に関する考慮事項：「>」は、RFC 3986 [RFC3986]に従ってURIでパーセントエンコードする必要があります。
Published specification: The RECOGNIZE method of the MRCP protocol performs a recognition operation that matches input against a set of grammars. When matching against more than one grammar, it is sometimes necessary to use different weights for the individual grammars. These weights are not a property of the grammar resource itself but qualify the reference to that grammar for the particular recognition operation initiated by the RECOGNIZE method. The format of the proposed 'text/grammar-ref-list' media type is as follows:
公開された仕様：MRCPプロトコルのRECOGNIZEメソッドは、入力を一連の文法と照合する認識操作を実行します。複数の文法と照合する場合、個々の文法に異なる重みを使用する必要がある場合があります。これらの重みは、文法リソース自体のプロパティではありませんが、RECOGNIZEメソッドによって開始された特定の認識操作のその文法への参照を修飾します。提案されている「text / grammar-ref-list」メディアタイプの形式は次のとおりです。
body = *reference
reference = "<" uri ">" [parameters] CRLF
parameters = ";" parameter *(";" parameter)
parameter = attribute "=" value
This specification currently only defines a 'weight' parameter, but new parameters MAY be added through the "Grammar Reference List Parameters" IANA registry established through this specification. Example:
この仕様では現在「重み」パラメーターのみを定義していますが、この仕様で確立された「文法参照リストパラメーター」IANAレジストリーを介して新しいパラメーターを追加できます（MAY）。例：
<http://example.com/grammars/field1.gram>
<http://example.com/grammars/field2.gram>;weight="0.85"
<session:field3@form-level.store>;weight="0.9"
<http://example.com/grammars/universals.gram>;weight="0.75"
Applications that use this media type: MRCPv2 clients and servers
このメディアタイプを使用するアプリケーション：MRCPv2クライアントおよびサーバー
Additional information: none
追加情報：なし
Magic number(s): none
マジックナンバー：なし
Person & email address to contact for further information: Sarvi Shanmugham, sarvi@cisco.com
詳細について連絡する人とメールアドレス：Sarvi Shanmugham、sarvi @ cisco.com
Intended usage: This media type is expected to be used only in conjunction with MRCPv2.
使用目的：このメディアタイプは、MRCPv2との組み合わせでのみ使用することが想定されています。
IANA has registered the following new URI scheme. The information below follows the template given in RFC 4395 [RFC4395].
IANAは、次の新しいURIスキームを登録しました。以下の情報は、RFC 4395 [RFC4395]で提供されているテンプレートに従います。
URI scheme name: session
URIスキーム名：セッション
Status: Permanent
ステータス：永久
URI scheme syntax: The syntax of this scheme is identical to that defined for the "cid" scheme in Section 2 of RFC 2392 [RFC2392].
URIスキームの構文：このスキームの構文は、RFC 2392 [RFC2392]のセクション2で「cid」スキームに対して定義されたものと同じです。
URI scheme semantics: The URI is intended to identify a data resource previously given to the network computing resource. The purpose of this scheme is to permit access to the specific resource for the lifetime of the session with the entity storing the resource. The media type of the resource CAN vary. There is no explicit mechanism for communication of the media type. This scheme is currently widely used internally by existing implementations, and the registration is intended to provide information in the rare (and unfortunate) case that the scheme is used elsewhere. The scheme SHOULD NOT be used for open Internet protocols.
URIスキームのセマンティクス：URIは、以前にネットワークコンピューティングリソースに与えられたデータリソースを識別することを目的としています。このスキームの目的は、リソースを格納しているエンティティとのセッションの存続期間中、特定のリソースへのアクセスを許可することです。リソースのメディアタイプはさまざまです。メディアタイプの通信に明示的なメカニズムはありません。このスキームは現在、既存の実装によって内部的に広く使用されており、登録は、スキームが他の場所で使用されるというまれな（そして不幸な）場合に情報を提供することを目的としています。このスキームは、オープンインターネットプロトコルでは使用しないでください。
Encoding considerations: There are no other encoding considerations for the 'session' URIs not described in RFC 3986 [RFC3986]
エンコーディングに関する考慮事項：RFC 3986 [RFC3986]に記載されていない「セッション」URIには、他のエンコーディングに関する考慮事項はありません。
Applications/protocols that use this URI scheme name: This scheme name is used by MRCPv2 clients and servers.
このURIスキーム名を使用するアプリケーション/プロトコル：このスキーム名は、MRCPv2クライアントおよびサーバーによって使用されます。
Interoperability considerations: Note that none of the resources are accessible after the MCRPv2 session ends, hence the name of the scheme. For clients who establish one MRCPv2 session only for the entire speech application being implemented, this is sufficient, but clients who create, terminate, and recreate MRCP sessions for performance or scalability reasons will lose access to resources established in the earlier session(s).
相互運用性の考慮事項：MCRPv2セッションの終了後はリソースにアクセスできないため、スキームの名前に注意してください。実装されている音声アプリケーション全体に対してのみ1つのMRCPv2セッションを確立するクライアントの場合、これで十分ですが、パフォーマンスまたはスケーラビリティの理由でMRCPセッションを作成、終了、および再作成するクライアントは、以前のセッションで確立されたリソースにアクセスできなくなります。
Security considerations: Generic security considerations for URIs described in RFC 3986 [RFC3986] apply to this scheme as well. The URIs defined here provide an identification mechanism only. Given that the communication channel between client and server is secure, that the server correctly accesses the resource associated with the URI, and that the server ensures session-only lifetime and access for each URI, the only additional security issues are those of the types of media referred to by the URI.
セキュリティに関する考慮事項：RFC 3986 [RFC3986]で説明されているURIの一般的なセキュリティに関する考慮事項は、このスキームにも適用されます。ここで定義されたURIは、識別メカニズムのみを提供します。クライアントとサーバー間の通信チャネルが安全であり、サーバーがURIに関連付けられたリソースに正しくアクセスし、サーバーが各URIのセッションのみの存続期間とアクセスを保証している場合、追加のセキュリティ問題は、 URIによって参照されるメディア。
Contact: Sarvi Shanmugham, sarvi@cisco.com
連絡先：servi shanmugham、servisisco.com
Author/Change controller: IESG, iesg@ietf.org
References: This specification, particularly Sections 6.2.7, 8.5.2, 9.5.1, and 9.9.
参照：この仕様、特にセクション6.2.7、8.5.2、9.5.1、および9.9。
IANA has registered the following SDP parameter values. The information for each follows the template given in RFC 4566 [RFC4566], Appendix B.
IANAは、次のSDPパラメータ値を登録しています。それぞれの情報は、RFC 4566 [RFC4566]、付録Bで提供されているテンプレートに従います。
"TCP/MRCPv2" value of the "proto" parameter
「proto」パラメータの「TCP / MRCPv2」値
Contact name, email address, and telephone number: Sarvi Shanmugham, sarvi@cisco.com, +1.408.902.3875
連絡先名、電子メールアドレス、および電話番号：Sarvi Shanmugham、sarvi @ cisco.com、+ 1.408.902.3875
Name being registered (as it will appear in SDP): TCP/MRCPv2
登録されている名前（SDPに表示されます）：TCP / MRCPv2
Long-form name in English: MCRPv2 over TCP
英語の長い形式の名前：MCRPv2 over TCP
Type of name: proto
名前のタイプ：proto
Explanation of name: This name represents the MCRPv2 protocol carried over TCP.
名前の説明：この名前は、TCPで伝送されるMCRPv2プロトコルを表します。
Reference to specification of name: RFC 6787
名前の仕様への参照：RFC 6787
"TCP/TLS/MRCPv2" value of the "proto" parameter
「proto」パラメータの「TCP / TLS / MRCPv2」値
Contact name, email address, and telephone number: Sarvi Shanmugham, sarvi@cisco.com, +1.408.902.3875
連絡先名、電子メールアドレス、および電話番号：Sarvi Shanmugham、sarvi @ cisco.com、+ 1.408.902.3875
Name being registered (as it will appear in SDP): TCP/TLS/MRCPv2
Long-form name in English: MCRPv2 over TLS over TCP
英語の長い形式の名前：MCRPv2 over TLS over TCP
Type of name: proto
名前のタイプ：proto
Explanation of name: This name represents the MCRPv2 protocol carried over TLS over TCP.
名前の説明：この名前は、TLS over TCPで伝送されるMCRPv2プロトコルを表します。
Reference to specification of name: RFC 6787
名前の仕様への参照：RFC 6787
"resource" value of the "att-field" parameter
「att-field」パラメータの「resource」値
Contact name, email address, and telephone number: Sarvi Shanmugham, sarvi@cisco.com, +1.408.902.3875
連絡先名、電子メールアドレス、および電話番号：Sarvi Shanmugham、sarvi @ cisco.com、+ 1.408.902.3875
Attribute name (as it will appear in SDP): resource
属性名（SDPに表示されるとおり）：リソース
Long-form attribute name in English: MRCPv2 resource type
英語の長い形式の属性名：MRCPv2リソースタイプ
Type of attribute: media-level
属性のタイプ：メディアレベル
Subject to charset attribute? no
文字セット属性の対象ですか？番号
Explanation of attribute: See Section 4.2 of RFC 6787 for description and examples.
属性の説明：説明と例については、RFC 6787のセクション4.2をご覧ください。
Specification of appropriate attribute values: See section Section 13.1.1 of RFC 6787.
適切な属性値の指定：RFC 6787のセクション13.1.1をご覧ください。
"channel" value of the "att-field" parameter
「att-field」パラメータの「channel」値
Contact name, email address, and telephone number: Sarvi Shanmugham, sarvi@cisco.com, +1.408.902.3875
連絡先名、電子メールアドレス、および電話番号：Sarvi Shanmugham、sarvi @ cisco.com、+ 1.408.902.3875
Attribute name (as it will appear in SDP): channel
属性名（SDPに表示されるとおり）：チャネル
Long-form attribute name in English: MRCPv2 resource channel identifier
英語の長い形式の属性名：MRCPv2リソースチャネル識別子
Type of attribute: media-level
属性のタイプ：メディアレベル
Subject to charset attribute? no
文字セット属性の対象ですか？番号
Explanation of attribute: See Section 4.2 of RFC 6787 for description and examples.
属性の説明：説明と例については、RFC 6787のセクション4.2をご覧ください。
Specification of appropriate attribute values: See Section 4.2 and the "channel-id" ABNF production rules of RFC 6787.
適切な属性値の指定：セクション4.2およびRFC 6787の「channel-id」ABNF生成規則を参照してください。
"cmid" value of the "att-field" parameter
「att-field」パラメータの「cmid」値
Contact name, email address, and telephone number: Sarvi Shanmugham, sarvi@cisco.com, +1.408.902.3875
連絡先名、電子メールアドレス、および電話番号：Sarvi Shanmugham、sarvi @ cisco.com、+ 1.408.902.3875
Attribute name (as it will appear in SDP): cmid
属性名（SDPに表示されるとおり）：cmid
Long-form attribute name in English: MRCPv2 resource channel media identifier
英語の長い形式の属性名：MRCPv2リソースチャネルメディア識別子
Type of attribute: media-level
属性のタイプ：メディアレベル
Subject to charset attribute? no
文字セット属性の対象ですか？番号
Explanation of attribute: See Section 4.4 of RFC 6787 for description and examples.
属性の説明：説明と例については、RFC 6787のセクション4.4をご覧ください。
Specification of appropriate attribute values: See Section 4.4 and the "cmid-attribute" ABNF production rules of RFC 6787.
適切な属性値の指定：セクション4.4およびRFC 6787の「cmid-attribute」ABNF生成規則を参照してください。
The following is an example of a typical MRCPv2 session of speech synthesis and recognition between a client and a server. Although the SDP "s=" attribute in these examples has a text description value to assist in understanding the examples, please keep in mind that RFC 3264 [RFC3264] recommends that messages actually put on the wire use a space or a dash.
以下は、クライアントとサーバー間の音声合成と認識の典型的なMRCPv2セッションの例です。これらの例のSDP "s ="属性には、例の理解に役立つテキストの説明の値がありますが、RFC 3264 [RFC3264]では、実際にネットワークに送信されるメッセージにはスペースまたはダッシュを使用することを推奨していることに注意してください。
The figure below illustrates opening a session to the MRCPv2 server. This exchange does not allocate a resource or setup media. It simply establishes a SIP session with the MRCPv2 server.
次の図は、MRCPv2サーバーへのセッションの開始を示しています。この交換では、リソースやセットアップメディアは割り当てられません。単にMRCPv2サーバーとのSIPセッションを確立します。
C->S: INVITE sip:mresources@example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bg1 Max-Forwards:6 To:MediaServer <sip:mresources@example.com> From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:323123 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:...
C-> S：INVITE sip：mresources@example.com SIP / 2.0 Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bg1 Max-Forwards：6 To：MediaServer <sip：mresources@example.com> From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：323123 INVITE Contact：<sip： sarvi@client.example.com> Content-Type：application / sdp Content-Length：...
v=0 o=sarvi 2614933546 2614933546 IN IP4 192.0.2.12 s=Set up MRCPv2 control and audio i=Initial contact c=IN IP4 192.0.2.12
v = 0 o = sarvi 2614933546 2614933546 IN IP4 192.0.2.12 s = MRCPv2コントロールとオーディオをセットアップi =初期コンタクトc = IN IP4 192.0.2.12
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bg1;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:323123 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bg1; received = 192.0.32.10 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：323123 INVITE連絡先：<sip：mresources@server.example.com> Content-Type：application / sdp Content-Length：...
v=0 o=- 3000000001 3000000001 IN IP4 192.0.2.11 s=Set up MRCPv2 control and audio i=Initial contact c=IN IP4 192.0.2.11
v = 0 o =-3000000001 3000000001 IN IP4 192.0.2.11 s = MRCPv2コントロールとオーディオをセットアップi =初期コンタクトc = IN IP4 192.0.2.11
C->S:
ACK sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bg2
Max-Forwards:6
To:MediaServer <sip:mresources@example.com>;tag=62784
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:323123 ACK
Content-Length:0
The client requests the server to create a synthesizer resource control channel to do speech synthesis. This also adds a media stream to send the generated speech. Note that, in this example, the client requests a new MRCPv2 TCP stream between the client and the server. In the following requests, the client will ask to use the existing connection.
クライアントは、音声合成を行うためのシンセサイザリソース制御チャネルを作成するようにサーバーに要求します。これにより、生成された音声を送信するメディアストリームも追加されます。この例では、クライアントがクライアントとサーバーの間で新しいMRCPv2 TCPストリームを要求することに注意してください。次のリクエストでは、クライアントは既存の接続を使用するように求めます。
C->S: INVITE sip:mresources@server.example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bg3 Max-Forwards:6 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:323124 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:...
C-> S：INVITE sip：mresources@server.example.com SIP / 2.0 Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bg3 Max-Forwards：6 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：323124 INVITE連絡先：<sip：sarvi@client.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=sarvi 2614933546 2614933547 IN IP4 192.0.2.12
s=Set up MRCPv2 control and audio
i=Add TCP channel, synthesizer and one-way audio
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:new
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=recvonly
a=mid:1
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bg3;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:323124 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bg3; received = 192.0.32.10 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：323124 INVITE連絡先：<sip：mresources@server.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=- 3000000001 3000000002 IN IP4 192.0.2.11
s=Set up MRCPv2 control and audio
i=Add TCP channel, synthesizer and one-way audio
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1
a=setup:passive
a=connection:new
a=channel:32AECB23433801@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
C->S:
ACK sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bg4
Max-Forwards:6
To:MediaServer <sip:mresources@example.com>;tag=62784
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:323124 ACK
Content-Length:0
This exchange allocates an additional resource control channel for a recognizer. Since a recognizer would need to receive an audio stream for recognition, this interaction also updates the audio stream to sendrecv, making it a two-way audio stream.
この交換により、認識機能に追加のリソース制御チャネルが割り当てられます。レコグナイザは認識のためにオーディオストリームを受信する必要があるため、このインタラクションはオーディオストリームもsendrecvに更新し、双方向オーディオストリームにします。
C->S: INVITE sip:mresources@server.example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bg5 Max-Forwards:6 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:323125 INVITE Contact:<sip:sarvi@client.example.com> Content-Type:application/sdp Content-Length:...
C-> S：INVITE sip：mresources@server.example.com SIP / 2.0 Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bg5 Max-Forwards：6 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：323125 INVITE連絡先：<sip：sarvi@client.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=sarvi 2614933546 2614933548 IN IP4 192.0.2.12
s=Set up MRCPv2 control and audio
i=Add recognizer and duplex the audio
c=IN IP4 192.0.2.12
t=0 0
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:existing
a=resource:speechsynth
a=cmid:1
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=recvonly
a=mid:1
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:existing
a=resource:speechrecog
a=cmid:2
m=audio 49180 RTP/AVP 0 96
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=sendonly
a=mid:2
S->C: SIP/2.0 200 OK Via:SIP/2.0/TCP client.atlanta.example.com:5060; branch=z9hG4bK74bg5;received=192.0.32.10 To:MediaServer <sip:mresources@example.com>;tag=62784 From:sarvi <sip:sarvi@example.com>;tag=1928301774 Call-ID:a84b4c76e66710 CSeq:323125 INVITE Contact:<sip:mresources@server.example.com> Content-Type:application/sdp Content-Length:...
S-> C：SIP / 2.0 200 OK Via：SIP / 2.0 / TCP client.atlanta.example.com:5060; branch = z9hG4bK74bg5; received = 192.0.32.10 To：MediaServer <sip：mresources@example.com>; tag = 62784 From：sarvi <sip：sarvi@example.com>; tag = 1928301774 Call-ID：a84b4c76e66710 CSeq：323125 INVITE連絡先：<sip：mresources@server.example.com> Content-Type：application / sdp Content-Length：...
v=0
o=- 3000000001 3000000003 IN IP4 192.0.2.11
s=Set up MRCPv2 control and audio
i=Add recognizer and duplex the audio
c=IN IP4 192.0.2.11
t=0 0
m=application 32416 TCP/MRCPv2 1
a=channel:32AECB23433801@speechsynth
a=cmid:1
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=sendonly
a=mid:1
m=application 32416 TCP/MRCPv2 1
a=channel:32AECB23433801@speechrecog
a=cmid:2
m=audio 48260 RTP/AVP 0
a=rtpmap:0 pcmu/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=recvonly
a=mid:2
C->S:
ACK sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bg6
Max-Forwards:6
To:MediaServer <sip:mresources@example.com>;tag=62784
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:323125 ACK
Content-Length:0
A MRCPv2 SPEAK request initiates speech.
MRCPv2 SPEAK要求は音声を開始します。
C->S: MRCP/2.0 ... SPEAK 543257 Channel-Identifier:32AECB23433801@speechsynth Kill-On-Barge-In:false Voice-gender:neutral Voice-age:25 Prosody-volume:medium Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543257 Channel-Identifier：32AECB23433801 @ speechsynth Kill-On-Barge-In：false Voice-gender：neutral Voice-age：25 Prosody-volume：medium Content-Type：application / ssml + xml Content-Length：...
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>You have 4 new messages.</s>
<s>The first is from Stephanie Williams
<mark name="Stephanie"/>
and arrived at <break/>
<say-as interpret-as="vxml:time">0345p</say-as>.</s>
<s>The subject is <prosody
rate="-20%">ski trip</prosody></s>
</p>
</speak>
S->C:
MRCP/2.0 ... 543257 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechsynth
Speech-Marker:timestamp=857205015059
The synthesizer hits the special marker in the message to be spoken and faithfully informs the client of the event.
シンセサイザは、メッセージ内の特別なマーカーにヒットして話し、クライアントにイベントを忠実に通知します。
S->C: MRCP/2.0 ... SPEECH-MARKER 543257 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechsynth
Speech-Marker:timestamp=857206027059;Stephanie
The synthesizer finishes with the SPEAK request.
シンセサイザはSPEAK要求で終了します。
S->C: MRCP/2.0 ... SPEAK-COMPLETE 543257 COMPLETE
Channel-Identifier:32AECB23433801@speechsynth
Speech-Marker:timestamp=857207685213;Stephanie
The recognizer is issued a request to listen for the customer choices.
認識機能には、顧客の選択を聞く要求が発行されます。
C->S: MRCP/2.0 ... RECOGNIZE 543258 Channel-Identifier:32AECB23433801@speechrecog Content-Type:application/srgs+xml Content-Length:...
C-> S：MRCP / 2.0 ... RECOGNIZE 543258 Channel-Identifier：32AECB23433801 @ speechrecog Content-Type：application / srgs + xml Content-Length：...
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" version="1.0" root="request">
<!-- 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>
S->C: MRCP/2.0 ... 543258 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
The client issues the next MRCPv2 SPEAK method.
クライアントは次のMRCPv2 SPEAKメソッドを発行します。
C->S: MRCP/2.0 ... SPEAK 543259 Channel-Identifier:32AECB23433801@speechsynth Kill-On-Barge-In:true Content-Type:application/ssml+xml Content-Length:...
C-> S：MRCP / 2.0 ... SPEAK 543259 Channel-Identifier：32AECB23433801 @ speechsynth Kill-On-Barge-In：true Content-Type：application / ssml + xml Content-Length：...
<?xml version="1.0"?>
<speak version="1.0"
xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/10/synthesis
http://www.w3.org/TR/speech-synthesis/synthesis.xsd"
xml:lang="en-US">
<p>
<s>Welcome to ABC corporation.</s>
<s>Who would you like to talk to?</s>
</p>
</speak>
S->C: MRCP/2.0 ... 543259 200 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechsynth
Speech-Marker:timestamp=857207696314
This next section of this ongoing example demonstrates how kill-on-barge-in support works. Since this last SPEAK request had Kill-On-Barge-In set to "true", when the recognizer (the server) generated the START-OF-INPUT event while a SPEAK was active, the client immediately issued a BARGE-IN-OCCURRED method to the synthesizer resource. The speech synthesizer then terminated playback and notified the client. The completion-cause code provided the indication that this was a kill-on-barge-in interruption rather than a normal completion.
この進行中の例のこの次のセクションでは、kill-on-barge-inサポートがどのように機能するかを示します。この最後のSPEAKリクエストではKill-On-Barge-Inが "true"に設定されていたため、SPEAKがアクティブなときに認識機能（サーバー）がSTART-OF-INPUTイベントを生成すると、クライアントはすぐにBARGE-IN-OCCURREDを発行しましたメソッドをシンセサイザリソースに追加します。その後、音声合成装置は再生を終了し、クライアントに通知しました。完了原因コードは、これが正常な完了ではなく割り込み割り込みであることを示していました。
Note that, since the recognition and synthesizer resources are in the same session on the same server, to obtain a faster response the server might have internally relayed the start-of-input condition to the synthesizer directly, before receiving the expected BARGE-IN-OCCURRED event. However, any such communication is outside the scope of MRCPv2.
認識リソースとシンセサイザリソースは同じサーバーの同じセッションにあるため、より高速な応答を取得するために、サーバーは入力の開始条件をシンセサイザに直接中継してから、予想されるBARGE-IN- OCCURREDイベント。ただし、そのような通信はMRCPv2の範囲外です。
S->C: MRCP/2.0 ... START-OF-INPUT 543258 IN-PROGRESS
Channel-Identifier:32AECB23433801@speechrecog
Proxy-Sync-Id:987654321
C->S: MRCP/2.0 ... BARGE-IN-OCCURRED 543259
Channel-Identifier:32AECB23433801@speechsynth
Proxy-Sync-Id:987654321
S->C: MRCP/2.0 ... 543259 200 COMPLETE
Channel-Identifier:32AECB23433801@speechsynth
Active-Request-Id-List:543258
Speech-Marker:timestamp=857206096314
S->C: MRCP/2.0 ... SPEAK-COMPLETE 543259 COMPLETE
Channel-Identifier:32AECB23433801@speechsynth
Completion-Cause:001 barge-in
Speech-Marker:timestamp=857207685213
The recognizer 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.
レコグナイザリソースは、音声ストリームを文法に一致させ、結果を生成しました。認識の結果は、RECOGNITION-COMPLETEイベントの一部としてサーバーから返されます。
S->C: MRCP/2.0 ... RECOGNITION-COMPLETE 543258 COMPLETE Channel-Identifier:32AECB23433801@speechrecog Completion-Cause:000 success Waveform-URI:<http://web.media.com/session123/audio.wav>; size=423523;duration=25432 Content-Type:application/nlsml+xml Content-Length:...
S-> C：MRCP / 2.0 ... RECOGNITION-COMPLETE 543258 COMPLETE Channel-Identifier：32AECB23433801 @ speechrecog Completion-Cause：000 success Waveform-URI：<http://web.media.com/session123/audio.wav> ; size = 423523; duration = 25432 Content-Type：application / nlsml + xml Content-Length：...
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="session:request1@form-level.store">
<interpretation>
<instance name="Person">
<ex:Person>
<ex:Name> Andre Roy </ex:Name>
</ex:Person>
</instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
Since the client was now finished with the session, including all resources, it issued a SIP BYE request to close the SIP session. This caused all control channels and resources allocated under the session to be deallocated.
これで、クライアントはすべてのリソースを含むセッションを終了したため、SIPセッションを閉じるためのSIP BYE要求を発行しました。これにより、セッションで割り当てられたすべての制御チャネルとリソースの割り当てが解除されました。
C->S: BYE sip:mresources@server.example.com SIP/2.0
Via:SIP/2.0/TCP client.atlanta.example.com:5060;
branch=z9hG4bK74bg7
Max-Forwards:6
From:Sarvi <sip:sarvi@example.com>;tag=1928301774
To:MediaServer <sip:mresources@example.com>;tag=62784
Call-ID:a84b4c76e66710
CSeq:323126 BYE
Content-Length:0
System: To which city will you be traveling? User: I want to go to Pittsburgh.
システム：どの都市に旅行しますか？ユーザー：ピッツバーグに行きたいです。
<?xml version="1.0"?>
<result xmlns="urn:ietf:params:xml:ns:mrcpv2"
xmlns:ex="http://www.example.com/example"
grammar="http://www.example.com/flight">
<interpretation confidence="0.6">
<instance>
<ex:airline>
<ex:to_city>Pittsburgh</ex:to_city>
<ex:airline>
<instance>
<input mode="speech">
I want to go to Pittsburgh
</input>
</interpretation>
<interpretation confidence="0.4"
<instance>
<ex:airline>
<ex:to_city>Stockholm</ex:to_city>
</ex:airline>
</instance>
<input>I want to go to Stockholm</input>
</interpretation>
</result>
System: What would you like? User: I would like 2 pizzas, one with pepperoni and cheese, one with sausage and a bottle of coke, to go.
システム：何が欲しいですか？ユーザー：ペパロニとチーズが入ったピザ、ソーセージとコーラのボトルが入ったピザ2枚を注文してください。
This example includes an order object which in turn contains objects named "food_item", "drink_item", and "delivery_method". The representation assumes there are no ambiguities in the speech or natural language processing. Note that this representation also assumes some level of intra-sentential anaphora resolution, i.e., to resolve the two "one"s as "pizza".
この例には、「food_item」、「drink_item」、および「delivery_method」という名前のオブジェクトを順に含む注文オブジェクトが含まれています。表現では、音声処理や自然言語処理に曖昧さがないことを前提としています。この表現は、ある程度の文内照応の解決、つまり2つの「1」を「ピザ」として解決することも想定していることに注意してください。
<?xml version="1.0"?>
<nl:result xmlns:nl="urn:ietf:params:xml:ns:mrcpv2"
xmlns="http://www.example.com/example"
grammar="http://www.example.com/foodorder">
<nl:interpretation confidence="1.0" >
<nl:instance>
<order>
<food_item confidence="1.0">
<pizza>
<ingredients confidence="1.0">
pepperoni
</ingredients>
<ingredients confidence="1.0">
cheese
</ingredients>
</pizza>
<pizza>
<ingredients>sausage</ingredients>
</pizza>
</food_item>
<drink_item confidence="1.0">
<size>2-liter</size>
</drink_item>
<delivery_method>to go</delivery_method>
</order>
</nl:instance>
<nl:input mode="speech">I would like 2 pizzas,
one with pepperoni and cheese, one with sausage
and a bottle of coke, to go.
</nl:input>
</nl:interpretation>
</nl:result>
A combination of DTMF input and speech is represented using nested input elements. For example: User: My pin is (dtmf 1 2 3 4)
DTMF入力と音声の組み合わせは、ネストされた入力要素を使用して表されます。例：ユーザー：私のピンは（dtmf 1 2 3 4）です
<input> <input mode="speech" confidence ="1.0" timestamp-start="2000-04-03T0:00:00" timestamp-end="2000-04-03T0:00:01.5">My pin is </input> <input mode="dtmf" confidence ="1.0" timestamp-start="2000-04-03T0:00:01.5" timestamp-end="2000-04-03T0:00:02.0">1 2 3 4 </input> </input> Note that grammars that recognize mixtures of speech and DTMF are not currently possible in SRGS; however, this representation might be needed for other applications of NLSML, and this mixture capability might be introduced in future versions of SRGS.
<input> <input mode = "speech" confidence = "1.0" timestamp-start = "2000-04-03T0：00：00" timestamp-end = "2000-04-03T0：00：01.5">私のピンは< / input> <input mode = "dtmf" confidence = "1.0" timestamp-start = "2000-04-03T0：00：01.5" timestamp-end = "2000-04-03T0：00：02.0"> 1 2 3 4 </ input> </ input>音声とDTMFの混合を認識する文法は、現在SRGSでは使用できないことに注意してください。ただし、この表現はNLSMLの他のアプリケーションで必要になる場合があり、この混合機能はSRGSの将来のバージョンで導入される可能性があります。
Natural language communication makes use of meta-dialog and meta-task utterances. This specification is flexible enough so that meta-utterances can be represented on an application-specific basis without requiring other standard markup.
自然言語のコミュニケーションは、メタダイアログとメタタスクの発話を利用します。この仕様は、他の標準マークアップを必要とせずにメタ発話をアプリケーション固有のベースで表すことができるように十分に柔軟です。
Here are two examples of how meta-task and meta-dialog utterances might be represented.
メタタスクとメタダイアログの発話がどのように表現されるかを示す2つの例を次に示します。
System: What toppings do you want on your pizza? User: What toppings do you have?
システム：ピザにどんなトッピングが欲しいですか？ユーザー：どんなトッピングがありますか？
<interpretation grammar="http://www.example.com/toppings">
<instance>
<question>
<questioned_item>toppings<questioned_item>
<questioned_property>
availability
</questioned_property>
</question>
</instance>
<input mode="speech">
what toppings do you have?
</input>
</interpretation>
User: slow down.
ユーザー：遅くなる。
<interpretation grammar="http://www.example.com/generalCommandsGrammar">
<instance>
<command>
<action>reduce speech rate</action>
<doer>system</doer>
</command>
</instance>
<input mode="speech">slow down</input>
</interpretation>
This specification can be used on an application-specific basis to represent utterances that contain unresolved anaphoric and deictic references. Anaphoric references, which include pronouns and definite noun phrases that refer to something that was mentioned in the preceding linguistic context, and deictic references, which refer to something that is present in the non-linguistic context, present similar problems in that there may not be sufficient unambiguous linguistic context to determine what their exact role in the interpretation should be. In order to represent unresolved anaphora and deixis using this specification, one strategy would be for the developer to define a more surface-oriented representation that leaves the specific details of the interpretation of the reference open. (This assumes that a later component is responsible for actually resolving the reference).
この仕様は、アプリケーション固有の基準で使用して、未解決の照応および直示の参照を含む発話を表すことができます。前の言語コンテキストで言及されたものを参照する代名詞と明確な名詞句を含む照応参照、および非言語コンテキストに存在する何かを参照する直示的参照は、解釈における彼らの正確な役割がどうあるべきかを決定するのに十分な明白な言語的文脈。この仕様を使用して未解決の照応とdeixisを表現するための1つの戦略は、開発者が参照の解釈の特定の詳細を開いたままにする、より表面指向の表現を定義することです。 （これは、後のコンポーネントが実際に参照を解決する責任があることを前提としています）。
Example: (ignoring the issue of representing the input from the pointing gesture.)
例：（ポインティングジェスチャーからの入力を表す問題を無視します。）
System: What do you want to drink? User: I want this. (clicks on picture of large root beer.)
システム：何を飲みたいですか？ユーザー：これが欲しい。 （大きなルートビールの写真をクリックします。）
<?xml version="1.0"?>
<nl:result xmlns:nl="urn:ietf:params:xml:ns:mrcpv2"
xmlns="http://www.example.com/example"
grammar="http://www.example.com/beverages.grxml">
<nl:interpretation>
<nl:instance>
<doer>I</doer>
<action>want</action>
<object>this</object>
</nl:instance>
<nl:input mode="speech">I want this</nl:input>
</nl:interpretation>
</nl:result>
For programming convenience, it is useful to be able to distinguish between individual items and sets containing one item in the XML representation of semantic results. For example, a pizza order might consist of exactly one pizza, but a pizza might contain zero or more toppings. Since there is no standard way of marking this distinction directly in XML, in the current framework, the developer is free to adopt any conventions that would convey this information in the XML markup. One strategy would be for the developer to wrap the set of items in a grouping element, as in the following example.
プログラミングの便宜上、セマンティックな結果のXML表現で、個々のアイテムと1つのアイテムを含むセットを区別できると便利です。たとえば、ピザの注文は1つのピザだけで構成されていても、ピザには0個以上のトッピングが含まれている場合があります。この区別をXMLで直接マークする標準的な方法がないため、現在のフレームワークでは、開発者はこの情報をXMLマークアップで伝達する規則を自由に採用できます。次の例のように、開発者が1つの戦略として、項目のセットをグループ化要素にラップすることになります。
<order>
<pizza>
<topping-group>
<topping>mushrooms</topping>
</topping-group>
</pizza>
<drink>coke</drink>
</order>
In this example, the programmer can assume that there is supposed to be exactly one pizza and one drink in the order, but the fact that there is only one topping is an accident of this particular pizza order.
この例では、プログラマーは注文にちょうど1つのピザと1つの飲み物があると想定できますが、トッピングが1つしかないというのはこの特定のピザ注文の偶然です。
Note that the client controls both the grammar and the semantics to be returned upon grammar matches, so the user of MRCPv2 is fully empowered to cause results to be returned in NLSML in such a way that the interpretation is clear to that user.
クライアントは文法と文法の一致時に返されるセマンティクスの両方を制御するため、MRCPv2のユーザーは、解釈が明確になるようにNLSMLで結果を返すように完全に権限が与えられていることに注意してください。
Extensibility in NLSML is provided via result content flexibility, as described in the discussions of meta-utterances and anaphora. NLSML can easily be used in sophisticated systems to convey application-specific information that more basic systems would not make use of, for example, defining speech acts.
NLSMLの拡張性は、メタ発話と照応の説明で説明されているように、結果コンテンツの柔軟性によって提供されます。 NLSMLは、洗練されたシステムで簡単に使用でき、アプリケーション固有の情報を伝えることができます。たとえば、より基本的なシステムでは、発話行為の定義を利用できません。
The following productions make use of the core rules defined in Section B.1 of RFC 5234 [RFC5234].
以下のプロダクションは、RFC 5234 [RFC5234]のセクションB.1で定義されたコアルールを利用しています。
LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
UTFCHAR = %x21-7E
/ UTF8-NONASCII
param = *pchar
quoted-string = SWS DQUOTE *(qdtext / quoted-pair )
DQUOTE
qdtext = LWS / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
/ "+" / "$" / ","
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
unreserved = alphanum / mark
pchar = unreserved / escaped
/ ":" / "@" / "&" / "=" / "+" / "$" / ","
alphanum = ALPHA / DIGIT
BOOLEAN = "true" / "false"
FLOAT = *DIGIT ["." *DIGIT]
escaped = "%" HEXDIG HEXDIG
エスケープ= "％" HEXDIG HEXDIG
fragment = *uric
uri = [ absoluteURI / relativeURI ]
[ "#" fragment ]
absoluteURI = scheme ":" ( hier-part / opaque-part )
relativeURI = ( net-path / abs-path / rel-path )
[ "?" query ]
hier-part = ( net-path / abs-path ) [ "?" query ]
net-path = "//" authority [ abs-path ]
abs-path = "/" path-segments
abs-path = "/"パスセグメント
rel-path = rel-segment [ abs-path ]
rel-segment = 1*( unreserved / escaped / ";" / "@"
/ "&" / "=" / "+" / "$" / "," )
opaque-part = uric-no-slash *uric
opaque-part = uric-no-slash * uric
uric = reserved / unreserved / escaped
uric-no-slash = unreserved / escaped / ";" / "?" / ":"
/ "@" / "&" / "=" / "+" / "$" / ","
path-segments = segment *( "/" segment )
segment = *pchar *( ";" param )
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = srvr / reg-name
srvr = [ [ userinfo "@" ] hostport ]
reg-name = 1*( unreserved / escaped / "$" / ","
/ ";" / ":" / "@" / "&" / "=" / "+" )
query = *uric
userinfo = ( user ) [ ":" password ] "@"
user = 1*( unreserved / escaped
/ user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";"
/ "?" / "/"
password = *( unreserved / escaped
/ "&" / "=" / "+" / "$" / "," )
hostport = host [ ":" port ]
hostport = host ["："ポート]
host = hostname / IPv4address / IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum / alphanum *( alphanum / "-" )
alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" )
alphanum
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
IPv6address = hexpart ["：" IPv4address]
hexpart = hexseq / hexseq "::" [ hexseq ] / "::"
[ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
port = 1*19DIGIT
; generic-message is the top-level rule
; generic-messageは最上位のルールです
generic-message = start-line message-header CRLF [ message-body ]
generic-message = start-line message-header CRLF [message-body]
message-body = *OCTET
start-line = request-line / response-line / event-line
request-line = mrcp-version SP message-length SP method-name SP request-id CRLF
request-line = mrcp-version SPメッセージ長SPメソッド名SPリクエストID CRLF
response-line = mrcp-version SP message-length SP request-id SP status-code SP request-state CRLF
response-line = mrcp-version SPメッセージ長SP要求ID SPステータスコードSP要求状態CRLF
event-line = mrcp-version SP message-length SP event-name SP request-id SP request-state CRLF
event-line = mrcp-version SP message-length SP event-name SP request-id SP request-state CRLF
method-name = generic-method
/ synthesizer-method
/ recognizer-method
/ recorder-method
/ verifier-method
generic-method = "SET-PARAMS" / "GET-PARAMS"
generic-method = "SET-PARAMS" / "GET-PARAMS"
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
request-state = "COMPLETE" / "IN-PROGRESS" / "PENDING"
event-name = synthesizer-event
/ recognizer-event
/ recorder-event
/ verifier-event
message-header = 1*(generic-header / resource-header / generic-field)
generic-field = field-name ":" [ field-value ]
field-name = token
field-value = *LWS field-content *( CRLF 1*LWS field-content)
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
resource-header = synthesizer-header
/ recognizer-header
/ recorder-header
/ verifier-header
generic-header = channel-identifier
/ accept
/ active-request-id-list
/ proxy-sync-id
/ accept-charset
/ content-type
/ content-id
/ content-base
/ content-encoding
/ content-location
/ content-length
/ fetch-timeout
/ cache-control
/ logging-tag
/ set-cookie
/ vendor-specific
; -- content-id is as defined in RFC 2392, RFC 2046 and RFC 5322
; -- accept and accept-charset are as defined in RFC 2616
mrcp-version = "MRCP" "/" 1*2DIGIT "." 1*2DIGIT
message-length = 1*19DIGIT
request-id = 1*10DIGIT
status-code = 3DIGIT channel-identifier = "Channel-Identifier" ":" channel-id CRLF
status-code = 3DIGIT channel-identifier = "Channel-Identifier" "："チャネルID CRLF
channel-id = 1*alphanum "@" 1*alphanum
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
proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF
content-base = "Content-Base" ":" absoluteURI CRLF
content-base = "Content-Base" "：" absoluteURI CRLF
content-length = "Content-Length" ":" 1*19DIGIT CRLF
content-type = "Content-Type" ":" media-type-value CRLF
content-type = "Content-Type" "：" media-type-value CRLF
media-type-value = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
パラメータ=属性 "="値
attribute = token
value = token / quoted-string
content-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
content-coding = token
content-location = "Content-Location" ":" ( absoluteURI / relativeURI ) CRLF
content-location = "Content-Location" "："（absoluteURI / relativeURI）CRLF
cache-control = "Cache-Control" ":"
[*WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )]
CRLF
fetch-timeout = "Fetch-Timeout" ":" 1*19DIGIT CRLF
cache-directive = "max-age" "=" delta-seconds
/ "max-stale" ["=" delta-seconds ]
/ "min-fresh" "=" delta-seconds
delta-seconds = 1*19DIGIT
logging-tag = "Logging-Tag" ":" 1*UTFCHAR CRLF
vendor-specific = "Vendor-Specific-Parameters" ":" [vendor-specific-av-pair *(";" vendor-specific-av-pair)] CRLF
vendor-specific = "Vendor-Specific-Parameters" "：" [vendor-specific-av-pair *（ ";" vendor-specific-av-pair）] CRLF
vendor-specific-av-pair = vendor-av-pair-name "=" value
vendor-specific-av-pair = vendor-av-pair-name "="値
vendor-av-pair-name = 1*UTFCHAR
set-cookie = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av / age-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
non-zero-digit = %x31-39
domain-av = "Domain=" domain-value
domain-value = <subdomain>
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
age-av = "Age=" delta-seconds
; Synthesizer ABNF
;シンセサイザーABNF
synthesizer-method = "SPEAK"
/ "STOP"
/ "PAUSE"
/ "RESUME"
/ "BARGE-IN-OCCURRED"
/ "CONTROL"
/ "DEFINE-LEXICON"
synthesizer-event = "SPEECH-MARKER" / "SPEAK-COMPLETE"
シンセサイザイベント= "SPEECH-MARKER" / "SPEAK-COMPLETE"
synthesizer-header = jump-size
/ kill-on-barge-in
/ speaker-profile
/ completion-cause
/ completion-reason
/ voice-parameter
/ prosody-parameter
/ speech-marker
/ speech-language
/ fetch-hint
/ audio-fetch-hint
/ failed-uri
/ failed-uri-cause
/ speak-restart
/ speak-length
/ load-lexicon
/ lexicon-search-order
jump-size = "Jump-Size" ":" speech-length-value CRLF
jump-size = "Jump-Size" "：" speech-length-value CRLF
speech-length-value = numeric-speech-length / text-speech-length
スピーチ長さ値=数値スピーチ長/テキストスピーチ長さ
text-speech-length = 1*UTFCHAR SP "Tag"
numeric-speech-length = ("+" / "-") positive-speech-length
positive-speech-length = 1*19DIGIT SP numeric-speech-unit
numeric-speech-unit = "Second"
/ "Word"
/ "Sentence"
/ "Paragraph"
kill-on-barge-in = "Kill-On-Barge-In" ":" BOOLEAN CRLF
kill-on-barge-in = "Kill-On-Barge-In" "：" BOOLEAN CRLF
speaker-profile = "Speaker-Profile" ":" uri CRLF
Speaker-profile = "Speaker-Profile" "：" uri CRLF
completion-cause = "Completion-Cause" ":" cause-code SP
cause-name CRLF
cause-code = 3DIGIT
cause-name = *VCHAR
completion-reason = "Completion-Reason" ":"
quoted-string CRLF
voice-parameter = voice-gender
/ voice-age
/ voice-variant
/ voice-name
voice-gender = "Voice-Gender:" voice-gender-value CRLF
voice-gender = "Voice-Gender：" voice-gender-value CRLF
voice-gender-value = "male" / "female" / "neutral"
voice-gender-value = "male" / "female" / "neutral"
voice-age = "Voice-Age:" 1*3DIGIT CRLF
voice-variant = "Voice-Variant:" 1*19DIGIT CRLF
voice-name = "Voice-Name:"
1*UTFCHAR *(1*WSP 1*UTFCHAR) CRLF
prosody-parameter = "Prosody-" prosody-param-name ":" prosody-param-value CRLF
prosody-parameter = "Prosody-" prosody-param-name "：" prosody-param-value CRLF
prosody-param-name = 1*VCHAR
prosody-param-value = 1*VCHAR
timestamp = "timestamp" "=" time-stamp-value
timestamp = "timestamp" "=" time-stamp-value
time-stamp-value = 1*20DIGIT
speech-marker = "Speech-Marker" ":"
timestamp
[";" 1*(UTFCHAR / %x20)] CRLF
speech-language = "Speech-Language" ":" 1*VCHAR CRLF
fetch-hint = "Fetch-Hint" ":" ("prefetch" / "safe") CRLF
audio-fetch-hint = "Audio-Fetch-Hint" ":"
("prefetch" / "safe" / "stream") CRLF
failed-uri = "Failed-URI" ":" absoluteURI CRLF
failed-uri = "Failed-URI" "：" absoluteURI CRLF
failed-uri-cause = "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
speak-restart = "Speak-Restart" ":" BOOLEAN CRLF speak-length = "Speak-Length" ":" positive-length-value CRLF
speak-restart = "Speak-Restart" "：" BOOLEAN CRLF speak-length = "Speak-Length" "："正の長さの値CRLF
positive-length-value = positive-speech-length / text-speech-length
正の長さの値=正のスピーチの長さ/テキストのスピーチの長さ
load-lexicon = "Load-Lexicon" ":" BOOLEAN CRLF
load-lexicon = "Load-Lexicon" "：" BOOLEAN CRLF
lexicon-search-order = "Lexicon-Search-Order" ":"
"<" absoluteURI ">" *(" " "<" absoluteURI ">") CRLF
; Recognizer ABNF
;レコグナイザーABNF
recognizer-method = recog-only-method / enrollment-method
レコグナイザメソッド= recog-only-method / enrollment-method
recog-only-method = "DEFINE-GRAMMAR"
/ "RECOGNIZE"
/ "INTERPRET"
/ "GET-RESULT"
/ "START-INPUT-TIMERS"
/ "STOP"
enrollment-method = "START-PHRASE-ENROLLMENT"
/ "ENROLLMENT-ROLLBACK"
/ "END-PHRASE-ENROLLMENT"
/ "MODIFY-PHRASE"
/ "DELETE-PHRASE"
recognizer-event = "START-OF-INPUT" / "RECOGNITION-COMPLETE" / "INTERPRETATION-COMPLETE"
レコグナイザイベント= "START-OF-INPUT" / "RECOGNITION-COMPLETE" / "INTERPRETATION-COMPLETE"
recognizer-header = recog-only-header / enrollment-header
レコグナイザヘッダー= recog-only-header / enrollment-header
recog-only-header = confidence-threshold
/ sensitivity-level
/ speed-vs-accuracy
/ n-best-list-length
/ input-type
/ no-input-timeout
/ recognition-timeout
/ waveform-uri
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ recognizer-context-block
/ start-input-timers
/ speech-complete-timeout
/ speech-incomplete-timeout
/ dtmf-interdigit-timeout
/ dtmf-term-timeout
/ dtmf-term-char
/ failed-uri
/ failed-uri-cause
/ save-waveform
/ media-type
/ new-audio-channel
/ speech-language
/ ver-buffer-utterance
/ recognition-mode
/ cancel-if-queue
/ hotword-max-duration
/ hotword-min-duration
/ interpret-text
/ dtmf-buffer-time
/ clear-dtmf-buffer
/ early-no-match
enrollment-header = num-min-consistent-pronunciations
/ consistency-threshold
/ clash-threshold
/ personal-grammar-uri
/ enroll-utterance
/ phrase-id
/ phrase-nl
/ weight
/ save-best-waveform
/ new-phrase-id
/ confusable-phrases-uri
/ abort-phrase-enrollment
confidence-threshold = "Confidence-Threshold" ":" FLOAT CRLF
Confidence-threshold = "Confidence-Threshold" "：" FLOAT CRLF
sensitivity-level = "Sensitivity-Level" ":" FLOAT CRLF
感度レベル= "感度レベル" "：" FLOAT CRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" ":" FLOAT CRLF
speed-vs-accuracy = "Speed-Vs-Accuracy" "：" FLOAT CRLF
n-best-list-length = "N-Best-List-Length" ":" 1*19DIGIT CRLF
n-best-list-length = "N-Best-List-Length" "：" 1 * 19DIGIT CRLF
input-type = "Input-Type" ":" inputs CRLF
inputs = "speech" / "dtmf"
no-input-timeout = "No-Input-Timeout" ":" 1*19DIGIT CRLF
no-input-timeout = "No-Input-Timeout" "：" 1 * 19DIGIT CRLF
recognition-timeout = "Recognition-Timeout" ":" 1*19DIGIT CRLF
authentication-timeout = "Recognition-Timeout" "：" 1 * 19DIGIT CRLF
waveform-uri = "Waveform-URI" ":" ["<" uri ">"
";" "size" "=" 1*19DIGIT
";" "duration" "=" 1*19DIGIT] CRLF
recognizer-context-block = "Recognizer-Context-Block" ":" [1*VCHAR] CRLF
cognizer-context-block = "Recognizer-Context-Block" "：" [1 * VCHAR] CRLF
start-input-timers = "Start-Input-Timers" ":" BOOLEAN CRLF
start-input-timers = "Start-Input-Timers" "：" BOOLEAN CRLF
speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*19DIGIT CRLF
speech-complete-timeout = "Speech-Complete-Timeout" "：" 1 * 19DIGIT CRLF
speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*19DIGIT CRLF
speech-incomplete-timeout = "Speech-Incomplete-Timeout" "：" 1 * 19DIGIT CRLF
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*19DIGIT CRLF
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" "：" 1 * 19DIGIT CRLF
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*19DIGIT CRLF
dtmf-term-timeout = "DTMF-Term-Timeout" "：" 1 * 19DIGIT CRLF
dtmf-term-char = "DTMF-Term-Char" ":" VCHAR CRLF
dtmf-term-char = "DTMF-Term-Char" "：" VCHAR CRLF
save-waveform = "Save-Waveform" ":" BOOLEAN CRLF
save-waveform = "Save-Waveform" "：" BOOLEAN CRLF
new-audio-channel = "New-Audio-Channel" ":" BOOLEAN CRLF
new-audio-channel = "New-Audio-Channel" "："ブールCRLF
recognition-mode = "Recognition-Mode" ":"
"normal" / "hotword" CRLF
cancel-if-queue = "Cancel-If-Queue" ":" BOOLEAN CRLF
cancel-if-queue = "Cancel-If-Queue" "："ブールCRLF
hotword-max-duration = "Hotword-Max-Duration" ":" 1*19DIGIT CRLF
hotword-max-duration = "Hotword-Max-Duration" "：" 1 * 19DIGIT CRLF
hotword-min-duration = "Hotword-Min-Duration" ":" 1*19DIGIT CRLF
hotword-min-duration = "Hotword-Min-Duration" "：" 1 * 19DIGIT CRLF
interpret-text = "Interpret-Text" ":" 1*VCHAR CRLF
dtmf-buffer-time = "DTMF-Buffer-Time" ":" 1*19DIGIT CRLF
clear-dtmf-buffer = "Clear-DTMF-Buffer" ":" BOOLEAN CRLF
clear-dtmf-buffer = "Clear-DTMF-Buffer" "：" BOOLEAN CRLF
early-no-match = "Early-No-Match" ":" BOOLEAN CRLF
early-no-match = "Early-No-Match" "：" BOOLEAN CRLF
num-min-consistent-pronunciations = "Num-Min-Consistent-Pronunciations" ":" 1*19DIGIT CRLF
num-min-consistent-pronunciations = "Num-Min-Consistent-Pronunciations" "：" 1 * 19DIGIT CRLF
consistency-threshold = "Consistency-Threshold" ":" FLOAT CRLF
consistency-threshold = "Consistency-Threshold" ":" FLOAT CRLF
clash-threshold = "Clash-Threshold" ":" FLOAT CRLF
clash-threshold = "Clash-Threshold" "：" FLOAT CRLF
personal-grammar-uri = "Personal-Grammar-URI" ":" uri CRLF
personal-grammar-uri = "Personal-Grammar-URI" "：" uri CRLF
enroll-utterance = "Enroll-Utterance" ":" BOOLEAN CRLF
enroll-utterance = "Enroll-Utterance" "：" BOOLEAN CRLF
phrase-id = "Phrase-ID" ":" 1*VCHAR CRLF
phrase-nl = "Phrase-NL" ":" 1*UTFCHAR CRLF
weight = "Weight" ":" FLOAT CRLF
重量= "重量" "：" FLOAT CRLF
save-best-waveform = "Save-Best-Waveform" ":" BOOLEAN CRLF
save-best-waveform = "Save-Best-Waveform" "："ブールCRLF
new-phrase-id = "New-Phrase-ID" ":" 1*VCHAR CRLF
confusable-phrases-uri = "Confusable-Phrases-URI" ":" uri CRLF
confusable-phrases-uri = "Confusable-Phrases-URI" "：" uri CRLF
abort-phrase-enrollment = "Abort-Phrase-Enrollment" ":" BOOLEAN CRLF
abort-phrase-enrollment = "Abort-Phrase-Enrollment" "："ブールCRLF
; Recorder ABNF
;レコーダーABNF
recorder-method = "RECORD" / "STOP" / "START-INPUT-TIMERS"
recorder-method = "RECORD" / "STOP" / "START-INPUT-TIMERS"
recorder-event = "START-OF-INPUT" / "RECORD-COMPLETE"
レコーダーイベント= "START-OF-INPUT" / "RECORD-COMPLETE"
recorder-header = sensitivity-level
/ no-input-timeout
/ completion-cause
/ completion-reason
/ failed-uri
/ failed-uri-cause
/ record-uri
/ media-type
/ max-time
/ trim-length
/ final-silence
/ capture-on-speech
/ ver-buffer-utterance
/ start-input-timers
/ new-audio-channel
record-uri = "Record-URI" ":" [ "<" uri ">"
";" "size" "=" 1*19DIGIT
";" "duration" "=" 1*19DIGIT] CRLF
media-type = "Media-Type" ":" media-type-value CRLF
media-type = "Media-Type" ":" media-type-value CRLF
max-time = "Max-Time" ":" 1*19DIGIT CRLF
trim-length = "Trim-Length" ":" 1*19DIGIT CRLF
final-silence = "Final-Silence" ":" 1*19DIGIT CRLF
capture-on-speech = "Capture-On-Speech " ":" BOOLEAN CRLF
capture-on-speech = "Capture-On-Speech" "：" BOOLEAN CRLF
; Verifier ABNF
; ABNFを確認する
verifier-method = "START-SESSION"
/ "END-SESSION"
/ "QUERY-VOICEPRINT"
/ "DELETE-VOICEPRINT"
/ "VERIFY"
/ "VERIFY-FROM-BUFFER"
/ "VERIFY-ROLLBACK"
/ "STOP"
/ "CLEAR-BUFFER"
/ "START-INPUT-TIMERS"
/ "GET-INTERMEDIATE-RESULT"
verifier-event = "VERIFICATION-COMPLETE" / "START-OF-INPUT"
verifier-event = "VERIFICATION-COMPLETE" / "START-OF-INPUT"
verifier-header = repository-uri
/ voiceprint-identifier
/ verification-mode
/ adapt-model
/ abort-model
/ min-verification-score
/ num-min-verification-phrases
/ num-max-verification-phrases
/ no-input-timeout
/ save-waveform
/ media-type
/ waveform-uri
/ voiceprint-exists
/ ver-buffer-utterance
/ input-waveform-uri
/ completion-cause
/ completion-reason
/ speech-complete-timeout
/ new-audio-channel
/ abort-verification
/ start-input-timers
/ input-type
repository-uri = "Repository-URI" ":" uri CRLF
repository-uri = "Repository-URI" ":" uri CRLF
voiceprint-identifier = "Voiceprint-Identifier" ":"
vid *[";" vid] CRLF
vid = 1*VCHAR ["." 1*VCHAR]
verification-mode = "Verification-Mode" ":" verification-mode-string
検証モード= "検証モード" "："検証モード文字列
verification-mode-string = "train" / "verify"
adapt-model = "Adapt-Model" ":" BOOLEAN CRLF
適応モデル= "適応モデル" "："ブールCRLF
abort-model = "Abort-Model" ":" BOOLEAN CRLF
abort-model = "Abort-Model" ":" BOOLEAN CRLF
min-verification-score = "Min-Verification-Score" ":" [ %x2D ] FLOAT CRLF
min-verification-score = "Min-Verification-Score" ":" [ %x2D ] FLOAT CRLF
num-min-verification-phrases = "Num-Min-Verification-Phrases" ":" 1*19DIGIT CRLF
num-min-verification-phrases = "Num-Min-Verification-Phrases" ":" 1*19DIGIT CRLF
num-max-verification-phrases = "Num-Max-Verification-Phrases" ":" 1*19DIGIT CRLF
num-max-verification-phrases = "Num-Max-Verification-Phrases" ":" 1*19DIGIT CRLF
voiceprint-exists = "Voiceprint-Exists" ":" BOOLEAN CRLF
voiceprint-exists = "Voiceprint-Exists" "：" BOOLEAN CRLF
ver-buffer-utterance = "Ver-Buffer-Utterance" ":" BOOLEAN CRLF
ver-buffer-utterance = "Ver-Buffer-Utterance" "：" BOOLEAN CRLF
input-waveform-uri = "Input-Waveform-URI" ":" uri CRLF
input-waveform-uri = "Input-Waveform-URI" ":" uri CRLF
abort-verification = "Abort-Verification " ":" BOOLEAN CRLF
abort-verification = "Abort-Verification" "：" BOOLEAN CRLF
The following productions add a new SDP session-level attribute. See Paragraph 5.
次のプロダクションは、新しいSDPセッションレベル属性を追加します。パラグラフ5を参照してください。
cmid-attribute = "a=cmid:" identification-tag
identification-tag = token
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:mrcpv2"
xmlns="urn:ietf:params:xml:ns:mrcpv2"
elementFormDefault="qualified"
attributeFormDefault="unqualified" >
<xs:annotation>
<xs:documentation> Natural Language Semantic Markup Schema
</xs:documentation>
</xs:annotation>
<xs:include schemaLocation="enrollment-schema.rng"/>
<xs:include schemaLocation="verification-schema.rng"/>
<xs:element name="result">
<xs:complexType>
<xs:sequence>
<xs:element name="interpretation" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="instance">
<xs:complexType mixed="true">
<xs:sequence minOccurs="0">
<xs:any namespace="##other" processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="input" minOccurs="0">
<xs:complexType mixed="true">
<xs:choice>
<xs:element name="noinput" minOccurs="0"/>
<xs:element name="nomatch" minOccurs="0"/>
<xs:element name="input" minOccurs="0"/>
</xs:choice>
<xs:attribute name="mode"
type="xs:string"
default="speech"/>
<xs:attribute name="confidence"
type="confidenceinfo"
default="1.0"/>
<xs:attribute name="timestamp-start"
type="xs:string"/>
<xs:attribute name="timestamp-end"
type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="confidence" type="confidenceinfo"
default="1.0"/>
<xs:attribute name="grammar" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="enrollment-result"
type="enrollment-contents"/>
<xs:element name="verification-result"
type="verification-contents"/>
</xs:sequence>
<xs:attribute name="grammar" type="xs:anyURI"
use="optional"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="confidenceinfo">
<xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/>
<xs:maxInclusive value="1.0"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<!-- MRCP Enrollment Schema
(See http://www.oasis-open.org/committees/relax-ng/spec.html)
-->
<grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:mrcpv2"
xmlns="http://relaxng.org/ns/structure/1.0">
<start>
<element name="enrollment-result">
<ref name="enrollment-content"/>
</element>
</start>
<define name="enrollment-content">
<interleave>
<element name="num-clashes">
<data type="nonNegativeInteger"/>
</element>
<element name="num-good-repetitions">
<data type="nonNegativeInteger"/>
</element>
<element name="num-repetitions-still-needed">
<data type="nonNegativeInteger"/>
</element>
<element name="consistency-status">
<choice>
<value>consistent</value>
<value>inconsistent</value>
<value>undecided</value>
</choice>
</element>
<optional>
<element name="clash-phrase-ids">
<oneOrMore>
<element name="item">
<data type="token"/>
</element>
</oneOrMore>
</element>
</optional>
<optional>
<element name="transcriptions">
<oneOrMore>
<element name="item">
<text/>
</element>
</oneOrMore>
</element>
</optional>
<optional>
<element name="confusable-phrases">
<oneOrMore>
<element name="item">
<text/>
</element>
</oneOrMore>
</element>
</optional>
</interleave>
</define>
</grammar>
16.3. Verification Results Schema Definition
<?xml version="1.0" encoding="UTF-8"?>
<!-- MRCP Verification Results Schema
(See http://www.oasis-open.org/committees/relax-ng/spec.html)
-->
<grammar datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:mrcpv2"
xmlns="http://relaxng.org/ns/structure/1.0">
<start>
<element name="verification-result">
<ref name="verification-contents"/>
</element>
</start>
<define name="verification-contents">
<element name="voiceprint">
<ref name="firstVoiceprintContent"/>
</element>
<zeroOrMore>
<element name="voiceprint">
<ref name="restVoiceprintContent"/>
</element>
</zeroOrMore>
</define>
<define name="firstVoiceprintContent">
<attribute name="id">
<data type="string"/>
</attribute>
<interleave>
<optional>
<element name="adapted">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="needmoredata">
<ref name="needmoredataContent"/>
</element>
</optional>
<optional>
<element name="incremental">
<ref name="firstCommonContent"/>
</element>
</optional>
<element name="cumulative">
<ref name="firstCommonContent"/>
</element>
</interleave>
</define>
<define name="restVoiceprintContent">
<attribute name="id">
<data type="string"/>
</attribute>
<element name="cumulative">
<ref name="restCommonContent"/>
</element>
</define>
<define name="firstCommonContent">
<interleave>
<element name="decision">
<ref name="decisionContent"/>
</element>
<optional>
<element name="utterance-length">
<ref name="utterance-lengthContent"/>
</element>
</optional>
<optional>
<element name="device">
<ref name="deviceContent"/>
</element>
</optional>
<optional>
<element name="gender">
<ref name="genderContent"/>
</element>
</optional>
<zeroOrMore>
<element name="verification-score">
<ref name="verification-scoreContent"/>
</element>
</zeroOrMore>
</interleave>
</define>
<define name="restCommonContent">
<interleave>
<optional>
<element name="decision">
<ref name="decisionContent"/>
</element>
</optional>
<optional>
<element name="device">
<ref name="deviceContent"/>
</element>
</optional>
<optional>
<element name="gender">
<ref name="genderContent"/>
</element>
</optional>
<zeroOrMore>
<element name="verification-score">
<ref name="verification-scoreContent"/>
</element>
</zeroOrMore>
</interleave>
</define>
<define name="decisionContent">
<choice>
<value>accepted</value>
<value>rejected</value>
<value>undecided</value>
</choice>
</define>
<define name="needmoredataContent">
<data type="boolean"/>
</define>
<define name="utterance-lengthContent">
<data type="nonNegativeInteger"/>
</define>
<define name="deviceContent">
<choice>
<value>cellular-phone</value>
<value>electret-phone</value>
<value>carbon-button-phone</value>
<value>unknown</value>
</choice>
</define>
<define name="genderContent">
<choice>
<value>male</value>
<value>female</value>
<value>unknown</value>
</choice>
</define>
<define name="verification-scoreContent">
<data type="float">
<param name="minInclusive">-1</param>
<param name="maxInclusive">1</param>
</data>
</define>
</grammar>
[ISO.8859-1.1987] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO Standard 8859-1, 1987.
[ISO.8859-1.1987]国際標準化機構、「情報技術-8ビットシングルバイトコードグラフィック-文字セット-パート1：ラテンアルファベットNo. 1、JTC1 / SC2」、ISO標準8859-1、1987。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.
[RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.
[RFC2616] 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.
[RFC2616] 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.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「メディアストリームのセッション記述プロトコル（SDP）セキュリティ記述」、RFC 4568、2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 5646、2009年9月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「Session Description Protocol（SDP）Grouping Framework」、RFC 5888、2010年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、Lawrence、S。、およびA. Jeffrey、「Session Initiation Protocol（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]バース、A。、「HTTP状態管理メカニズム」、RFC 6265、2011年4月。
[W3C.REC-semantic-interpretation-20070405] Tichelen, L. and D. Burke, "Semantic Interpretation for Speech Recognition (SISR) Version 1.0", World Wide Web Consortium Recommendation REC-semantic-interpretation-20070405, April 2007, <http://www.w3.org/TR/2007/ REC-semantic-interpretation-20070405>.
[W3C.REC-semantic-interpretation-20070405] Tichelen、L.およびD. Burke、「Semantic Interpretation for Speech Recognition（SISR）Version 1.0」、World Wide Web Consortium Recommendation REC-semantic-interpretation-20070405、2007年4月、< http://www.w3.org/TR/2007/ REC-semantic-interpretation-20070405>。
[W3C.REC-speech-grammar-20040316] McGlashan, S. and A. Hunt, "Speech Recognition Grammar Specification Version 1.0", World Wide Web Consortium Recommendation REC-speech-grammar-20040316, March 2004, <http://www.w3.org/TR/2004/REC-speech-grammar-20040316>.
[W3C.REC-speech-grammar-20040316] McGlashan、S。およびA. Hunt、「Speech Recognition Grammar Specification Version 1.0」、World Wide Web Consortium Recommendation REC-speech-grammar-20040316、2004年3月、<http：// www.w3.org/TR/2004/REC-speech-grammar-20040316>。
[W3C.REC-speech-synthesis-20040907] Walker, M., Burnett, D., and A. Hunt, "Speech Synthesis Markup Language (SSML) Version 1.0", World Wide Web Consortium Recommendation REC-speech-synthesis-20040907, September 2004, <http://www.w3.org/TR/2004/REC-speech-synthesis-20040907>.
[W3C.REC-speech-synthesis-20040907] Walker, M., Burnett, D., and A. Hunt, "Speech Synthesis Markup Language (SSML) Version 1.0", World Wide Web Consortium Recommendation REC-speech-synthesis-20040907, September 2004, <http://www.w3.org/TR/2004/REC-speech-synthesis-20040907>.
[W3C.REC-xml-names11-20040204] Layman, A., Bray, T., Hollander, D., and R. Tobin, "Namespaces in XML 1.1", World Wide Web Consortium First Edition REC-xml-names11-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-names11-20040204>.
[W3C.REC-xml-names11-20040204] Layman、A.、Bray、T.、Hollander、D。、およびR. Tobin、「Namespaces in XML 1.1」、World Wide Web Consortium First Edition REC-xml-names11- 20040204、2004年2月、<http://www.w3.org/TR/2004/REC-xml-names11-20040204>。
[ISO.8601.1988] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
[ISO.8601.1988]国際標準化機構、「データ要素と交換フォーマット-情報交換-日付と時刻の表現」、ISO標準8601、1988年6月。
[Q.23] International Telecommunications Union, "Technical Features of Push-Button Telephone Sets", ITU-T Q.23, 1993.
[Q.23]国際電気通信連合、「押しボタン式電話機の技術的特徴」、ITU-T Q.23、1993。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217] Ford-Hutchinson、P。、「Secureting FTP with TLS」、RFC 4217、2005年10月。
[RFC4267] Froumentin, M., "The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ ccxml+xml, and application/pls+xml", RFC 4267, November 2005.
[RFC4267] Froumentin、M。、「W3C音声インターフェースフレームワークのメディアタイプ：application / voicexml + xml、application / ssml + xml、application / srgs、application / srgs + xml、application / ccxml + xml、application / pls + xml」、RFC 4267、2005年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4313] Oran, D., "Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources", RFC 4313, December 2005.
[RFC4313] Oran、D。、「自動音声認識（ASR）、話者識別/話者検証（SI / SV）、および音声合成（TTS）リソースの分散制御の要件」、RFC 4313、2005年12月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
[RFC4463] Shanmugham, S., Monaco, P., and B. Eberman, "A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks", RFC 4463, April 2006.
[RFC4463] Shanmugham、S.、Monaco、P.、and B. Eberman、 "A Media Resource Control Protocol（MRCP）Developed by Cisco、Nuance、and Speechworks"、RFC 4463、2006年4月。
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、およびテレフォニーシグナルのRTPペイロード」、RFC 4733、2006年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]バース、A。、「The Web Origin Concept」、RFC 6454、2011年12月。
[W3C.REC-emma-20090210] Johnston, M., Baggia, P., Burnett, D., Carter, J., Dahl, D., McCobb, G., and D. Raggett, "EMMA: Extensible MultiModal Annotation markup language", World Wide Web Consortium Recommendation REC-emma-20090210, February 2009, <http://www.w3.org/TR/2009/REC-emma-20090210>.
[W3C.REC-emma-20090210] Johnston, M., Baggia, P., Burnett, D., Carter, J., Dahl, D., McCobb, G., and D. Raggett, "EMMA: Extensible MultiModal Annotation markup language", World Wide Web Consortium Recommendation REC-emma-20090210, February 2009, <http://www.w3.org/TR/2009/REC-emma-20090210>.
[W3C.REC-pronunciation-lexicon-20081014] Baggia, P., Bagshaw, P., Burnett, D., Carter, J., and F. Scahill, "Pronunciation Lexicon Specification (PLS)", World Wide Web Consortium Recommendation REC-pronunciation-lexicon-20081014, October 2008, <http://www.w3.org/TR/2008/ REC-pronunciation-lexicon-20081014>.
[W3C.REC-pronunciation-lexicon-20081014] Baggia、P.、Bagshaw、P.、Burnett、D.、Carter、J。、およびF. Scahill、「Pronunciation Lexicon Specification（PLS）」、World Wide Web Consortium Recommendation REC-pronunciation-lexicon-20081014、2008年10月、<http://www.w3.org/TR/2008/ REC-pronunciation-lexicon-20081014>。
[W3C.REC-voicexml20-20040316] Danielsen, P., Porter, B., Hunt, A., Rehor, K., Lucas, B., Burnett, D., Ferrans, J., Tryphonas, S., McGlashan, S., and J. Carter, "Voice Extensible Markup Language (VoiceXML) Version 2.0", World Wide Web Consortium Recommendation REC-voicexml20-20040316, March 2004, <http://www.w3.org/TR/2004/REC-voicexml20-20040316>.
[W3C.REC-voicexml20-20040316] Danielsen, P., Porter, B., Hunt, A., Rehor, K., Lucas, B., Burnett, D., Ferrans, J., Tryphonas, S., McGlashan, S., and J. Carter, "Voice Extensible Markup Language (VoiceXML) Version 2.0", World Wide Web Consortium Recommendation REC-voicexml20-20040316, March 2004, <http://www.w3.org/TR/2004/REC-voicexml20-20040316>.
[refs.javaSpeechGrammarFormat] Sun Microsystems, "Java Speech Grammar Format Version 1.0", October 1998.
[refs.javaSpeechGrammarFormat] Sun Microsystems, "Java Speech Grammar Format Version 1.0", October 1998.
Pierre Forgues Nuance Communications Ltd. 1500 University Street Suite 935 Montreal, Quebec Canada H3A 3S7
Pierre Forgues Nuance Communications Ltd. 1500 University Street Suite 935 Montreal, Quebec Canada H3A 3S7
EMail: forgues@nuance.com
Charles Galles Intervoice, Inc. 17811 Waterview Parkway Dallas, Texas 75252 USA
Charles Galles Intervoice、Inc. 17811 Waterview Parkway Dallas、Texas 75252 USA
EMail: charles.galles@intervoice.com
Klaus Reifenrath Scansoft, Inc Guldensporenpark 32 Building D 9820 Merelbeke Belgium
Klaus Reifenrath Scansoft、Inc Guldensporenpark 32 Building D 9820 Merelbekeベルギー
EMail: klaus.reifenrath@scansoft.com
Andre Gillet (Nuance Communications) Andrew Hunt (ScanSoft) Andrew Wahbe (Genesys) Aaron Kneiss (ScanSoft) Brian Eberman (ScanSoft) Corey Stohs (Cisco Systems, Inc.) Dave Burke (VoxPilot) Jeff Kusnitz (IBM Corp) Ganesh N. Ramaswamy (IBM Corp) Klaus Reifenrath (ScanSoft) Kristian Finlator (ScanSoft) Magnus Westerlund (Ericsson) Martin Dragomirecky (Cisco Systems, Inc.) Paolo Baggia (Loquendo) Peter Monaco (Nuance Communications) Pierre Forgues (Nuance Communications) Ran Zilca (IBM Corp) Suresh Kaliannan (Cisco Systems, Inc.) Skip Cave (Intervoice, Inc.) Thomas Gal (LumenVox)
Andre Gillet (Nuance Communications) Andrew Hunt (ScanSoft) Andrew Wahbe (Genesys) Aaron Kneiss (ScanSoft) Brian Eberman (ScanSoft) Corey Stohs (Cisco Systems, Inc.) Dave Burke (VoxPilot) Jeff Kusnitz (IBM Corp) Ganesh N. Ramaswamy (IBM Corp) Klaus Reifenrath (ScanSoft) Kristian Finlator (ScanSoft) Magnus Westerlund (Ericsson) Martin Dragomirecky (Cisco Systems, Inc.) Paolo Baggia (Loquendo) Peter Monaco (Nuance Communications) Pierre Forgues (Nuance Communications) Ran Zilca (IBM Corp) Suresh Kaliannan (Cisco Systems, Inc.) Skip Cave (Intervoice, Inc.) Thomas Gal (LumenVox)
The chairs of the SPEECHSC work group are Eric Burger (Georgetown University) and Dave Oran (Cisco Systems, Inc.).
SPEECHSCワークグループの議長は、Eric Burger（ジョージタウン大学）とDave Oran（Cisco Systems、Inc.）です。
Many thanks go in particular to Robert Sparks, Alex Agranovsky, and Henry Phan, who were there at the end to dot all the i's and cross all the t's.
特にすべてのiをドットで囲み、すべてのtを越えるために最後にいたRobert Sparks、Alex Agranovsky、およびHenry Phanに特に感謝します。
Authors' Addresses
Authors' Addresses
Daniel C. Burnett Voxeo 189 South Orange Avenue #1000 Orlando, FL 32801 USA
Daniel C. Burnett Voxeo 189 South Orange Avenue＃1000 Orlando、FL 32801 USA
EMail: dburnett@voxeo.com
Saravanan Shanmugham Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Saravanan Shanmugham Cisco Systems、Inc. 170 W. Tasman Dr. San Jose、CA 95134 USA
EMail: sarvi@cisco.com