From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc6787.txt | 12547 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 12547 insertions(+)
 create mode 100644 doc/rfc/rfc6787.txt

(limited to 'doc/rfc/rfc6787.txt')

diff --git a/doc/rfc/rfc6787.txt b/doc/rfc/rfc6787.txt
new file mode 100644
index 0000000..ca651b7
--- /dev/null
+++ b/doc/rfc/rfc6787.txt
@@ -0,0 +1,12547 @@
+
+
+
+
+
+
+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)
+
+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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 1]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 2]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+       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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 3]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+     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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 4]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+       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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 5]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+       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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 6]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+     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
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 7]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 8]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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 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 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.)
+
+2.  Document Conventions
+
+   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].
+
+   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.
+
+   All the mechanisms specified in this document are described in both
+   prose and an augmented Backus-Naur form (ABNF [RFC5234]).
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                    [Page 9]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+2.1.  Definitions
+
+   Media Resource
+                  An entity on the speech processing server that can be
+                  controlled through 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 Client
+                  An entity controlling one or more Media Resources
+                  through MRCPv2 ("Client" for short).
+
+   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]).
+
+   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.
+
+2.2.  State-Machine Diagrams
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 10]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+2.3.  URI Schemes
+
+   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.
+
+3.  Architecture
+
+   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.
+
+   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.
+
+   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.
+
+   SIP also establishes the media sessions between the client (or other
+   source/sink of media) and the MRCPv2 server using SDP "m=" lines.
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 11]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   The following diagram shows the general architecture of a system that
+   uses MRCPv2.  To simplify the diagram, only a few resources are
+   shown.
+
+     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
+
+3.1.  MRCPv2 Media Resource Types
+
+   An MRCPv2 server may offer one or more of the following media
+   processing resources to its clients.
+
+   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>.
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 12]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 13]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+3.2.  Server and Resource Addressing
+
+   The MRCPv2 server is a generic SIP server, and is thus addressed by a
+   SIP URI (RFC 3261 [RFC3261]).
+
+   For example:
+
+        sip:mrcpv2@example.net   or
+        sips:mrcpv2@example.net
+
+4.  MRCPv2 Basics
+
+   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.
+
+4.1.  Connecting to the Server
+
+   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.
+
+4.2.  Managing Resource Control Channels
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 14]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   resources.  Additional resource types and their associated methods/
+   events and state machines may be added as described below in
+   Section 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
+
+   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.
+
+   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".
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 15]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 16]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+4.3.  SIP Session Example
+
+   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.
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 17]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          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:...
+
+          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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 18]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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:...
+
+          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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 19]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          Contact:<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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 20]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          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:...
+
+          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:...
+
+          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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 21]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          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
+
+4.4.  Media Streams and RTP Ports
+
+   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.
+
+   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:
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 22]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   cmid-attribute     = "a=cmid:" identification-tag
+   identification-tag = token
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 23]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+4.5.  MRCPv2 Message Transport
+
+   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.
+
+   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.
+
+4.6.  MRCPv2 Session Termination
+
+   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.
+
+5.  MRCPv2 Specification
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 24]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+5.1.  Common Protocol Elements
+
+   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.
+
+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.
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 25]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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-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.
+
+   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.
+
+   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>
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 26]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+           <!-- 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.
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 27]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+5.2.  Request
+
+   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.
+
+   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
+
+   The mrcp-version field is the MRCP protocol version that is being
+   used by the client.
+
+   The message-length field specifies the length of the message,
+   including the start-line.
+
+   Details about the mrcp-version and message-length fields are given in
+   Section 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    =    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.
+
+   The server resource MUST use the client-assigned identifier in its
+   response to the request.  If the request does not complete
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 28]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   synchronously, future asynchronous events associated with this
+   request MUST carry the client-assigned request-id.
+
+   request-id     =    1*10DIGIT
+
+5.3.  Response
+
+   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.
+
+   response-line  =    mrcp-version SP message-length SP request-id
+                       SP status-code SP request-state 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.
+
+   The message-length field specifies the length of the message,
+   including the start-line.
+
+   Details about the mrcp-version and message-length fields are given in
+   Section 5.1.
+
+   The request-id used in the response MUST match the one sent in the
+   corresponding request message.
+
+   The status-code field is a 3-digit code representing the success or
+   failure or other status of the request.
+
+   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    =  "COMPLETE"
+                    /  "IN-PROGRESS"
+                    /  "PENDING"
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 29]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+5.4.  Status Codes
+
+   The status codes are classified under the Success (2xx), Client
+   Failure (4xx), and Server Failure (5xx) codes.
+
+     +------------+--------------------------------------------------+
+     | Code       | Meaning                                          |
+     +------------+--------------------------------------------------+
+     | 200        | Success                                          |
+     | 201        | Success with some optional header fields ignored |
+     +------------+--------------------------------------------------+
+
+                               Success (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)
+
+              +------------+--------------------------------+
+              | Code       | Meaning                        |
+              +------------+--------------------------------+
+              | 501        | Server Internal Error          |
+              | 502        | Protocol Version not supported |
+              | 503        | Reserved for future assignment |
+              | 504        | Message too large              |
+              +------------+--------------------------------+
+
+                           Server Failure (5xx)
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 30]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+5.5.  Events
+
+   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.
+
+   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.
+
+   The message-length field specifies the length of the message,
+   including the start-line.
+
+   Details about the mrcp-version and message-length fields are given in
+   Section 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       =  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.
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 31]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+6.  MRCPv2 Generic Methods, Headers, and Result Structure
+
+   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.
+
+6.1.  Generic Methods
+
+   MRCPv2 supports two generic methods for reading and writing the state
+   associated with a resource.
+
+   generic-method      =    "SET-PARAMS"
+                       /    "GET-PARAMS"
+
+   These are described in the following subsections.
+
+6.1.1.  SET-PARAMS
+
+   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.
+
+   If one or more of the header fields being sent is incorrect, error
+   403, 404, or 409 MUST be returned as follows:
+
+   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  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  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.
+
+   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.
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 32]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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
+
+6.1.2.  GET-PARAMS
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 33]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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"
+
+6.2.  Generic Message Headers
+
+   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).
+
+   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.
+
+   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.
+
+   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)].
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 34]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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
+
+6.2.1.  Channel-Identifier
+
+   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.
+
+   channel-identifier  = "Channel-Identifier" ":" channel-id CRLF
+   channel-id          = 1*alphanum "@" 1*alphanum
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 35]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+6.2.2.  Accept
+
+   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.
+
+6.2.3.  Active-Request-Id-List
+
+   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.
+
+   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.
+
+   The Active-Request-Id-List is only used in requests and responses,
+   not in events.
+
+   For example, if a STOP request with no Active-Request-Id-List is sent
+   to a synthesizer resource 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  =  "Active-Request-Id-List" ":"
+                              request-id *("," request-id) CRLF
+
+6.2.4.  Proxy-Sync-Id
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 36]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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    =  "Proxy-Sync-Id" ":" 1*VCHAR CRLF
+
+6.2.5.  Accept-Charset
+
+   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.
+
+6.2.6.  Content-Type
+
+   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.
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 37]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+6.2.7.  Content-ID
+
+   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.
+
+6.2.8.  Content-Base
+
+   The Content-Base entity-header MAY be used to specify the base URI
+   for resolving relative URIs within the entity.
+
+   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.
+
+6.2.9.  Content-Encoding
+
+   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-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
+
+   If multiple encodings have been applied to an entity, the content
+   encodings MUST be listed in the order in which they were applied.
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 38]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+6.2.10.  Content-Location
+
+   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  =  "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.
+
+   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.
+
+   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.
+
+6.2.11.  Content-Length
+
+   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.
+
+   content-length  =  "Content-Length" ":" 1*19DIGIT CRLF
+
+6.2.12.  Fetch Timeout
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 39]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   fetch-timeout       =   "Fetch-Timeout" ":" 1*19DIGIT CRLF
+
+6.2.13.  Cache-Control
+
+   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.
+
+   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.
+
+   The different cache-directive options allow the client to ask the
+   server to override the default cache expiration mechanisms:
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 40]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   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).
+
+   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.
+
+6.2.14.  Logging-Tag
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 41]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   personally identifiable information such as credit card numbers and
+   national identification numbers.
+
+   logging-tag    = "Logging-Tag" ":" 1*UTFCHAR CRLF
+
+6.2.15.  Set-Cookie
+
+   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.
+
+   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.
+
+ 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>
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 42]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+ 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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 43]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+6.2.16.  Vendor-Specific Parameters
+
+   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-av-pair  = vendor-av-pair-name "="
+                              value
+
+   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:
+
+   com.example.companyA.paramxyz=256
+   com.example.companyA.paramabc=High
+   com.example.companyB.paramxyz=Low
+
+   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.
+
+6.3.  Generic Result Structure
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 44]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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
+
+6.3.1.  Natural Language Semantics Markup Language
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 45]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+7.  Resource Discovery
+
+   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.
+
+   The SDP description MUST also contain "m=" lines describing the audio
+   capabilities and the coders the server supports.
+
+   In this example, the client uses the SIP OPTIONS method to query the
+   capabilities of the MRCPv2 server.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 46]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+        Accept:application/sdp
+        Accept-Encoding:gzip
+        Accept-Language:en
+        Supported:foo
+        Content-Type:application/sdp
+        Content-Length:...
+
+        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
+
+8.  Speech Synthesizer Resource
+
+   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.
+
+   This section applies for the following resource types:
+
+   o  speechsynth
+
+   o  basicsynth
+
+   The capabilities of these resources are defined in Section 3.1.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 47]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+8.1.  Synthesizer State Machine
+
+   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.
+
+   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
+
+8.2.  Synthesizer Methods
+
+   The synthesizer supports the following methods.
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 48]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   synthesizer-method   =  "SPEAK"
+                        /  "STOP"
+                        /  "PAUSE"
+                        /  "RESUME"
+                        /  "BARGE-IN-OCCURRED"
+                        /  "CONTROL"
+                        /  "DEFINE-LEXICON"
+
+8.3.  Synthesizer Events
+
+   The synthesizer can generate the following events.
+
+   synthesizer-event    =  "SPEECH-MARKER"
+                        /  "SPEAK-COMPLETE"
+
+8.4.  Synthesizer Header Fields
+
+   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
+
+8.4.1.  Jump-Size
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 49]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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".
+
+   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"
+
+8.4.2.  Kill-On-Barge-In
+
+   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      =   "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".
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 50]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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).
+
+8.4.3.  Speaker-Profile
+
+   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.
+
+   speaker-profile       =   "Speaker-Profile" ":" uri CRLF
+
+8.4.4.  Completion-Cause
+
+   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.
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 51]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+8.4.5.  Completion-Reason
+
+   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.
+
+   completion-reason   =   "Completion-Reason" ":"
+                           quoted-string 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.
+
+8.4.6.  Voice-Parameter
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 52]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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".
+
+8.4.7.  Prosody-Parameters
+
+   This set of header fields defines the prosody of the speech.
+
+   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.
+
+   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.
+
+   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.
+
+   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".
+
+8.4.8.  Speech-Marker
+
+   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].
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 53]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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).
+
+   timestamp           =   "timestamp" "=" time-stamp-value
+
+   time-stamp-value    =   1*20DIGIT
+
+   speech-marker       =   "Speech-Marker" ":"
+                           timestamp
+                           [";" 1*(UTFCHAR / %x20)] CRLF
+
+8.4.9.  Speech-Language
+
+   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.
+
+   speech-language     =   "Speech-Language" ":" 1*VCHAR CRLF
+
+8.4.10.  Fetch-Hint
+
+   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
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 54]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   be downloaded until actually referenced.  The default value is
+   "prefetch".  This header field MAY occur in SPEAK, SET-PARAMS, or
+   GET-PARAMS requests.
+
+   fetch-hint          =   "Fetch-Hint" ":" ("prefetch" / "safe") CRLF
+
+8.4.11.  Audio-Fetch-Hint
+
+   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.
+
+   audio-fetch-hint    =   "Audio-Fetch-Hint" ":"
+                           ("prefetch" / "safe" / "stream") CRLF
+
+8.4.12.  Failed-URI
+
+   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.
+
+   failed-uri          =   "Failed-URI" ":" absoluteURI CRLF
+
+8.4.13.  Failed-URI-Cause
+
+   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.
+
+   failed-uri-cause    =   "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 55]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+8.4.14.  Speak-Restart
+
+   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.
+
+   speak-restart       =   "Speak-Restart" ":" BOOLEAN CRLF
+
+8.4.15.  Speak-Length
+
+   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-length          =   "Speak-Length" ":" positive-length-value
+                             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"
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 56]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+8.4.16.  Load-Lexicon
+
+   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.
+
+   load-lexicon       =   "Load-Lexicon" ":" BOOLEAN CRLF
+
+8.4.17.  Lexicon-Search-Order
+
+   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.
+
+   lexicon-search-order =   "Lexicon-Search-Order" ":"
+             "<" absoluteURI ">" *(" " "<" absoluteURI ">") CRLF
+
+8.5.  Synthesizer Message Body
+
+   A synthesizer message can contain additional information associated
+   with the Request, Response, or Event in its message body.
+
+8.5.1.  Synthesizer Speech Data
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 57]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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
+
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 58]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   Content-Type:multipart/mixed; boundary="break"
+
+   --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:...
+
+   <?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
+
+8.5.2.  Lexicon Data
+
+   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).
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 59]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   Lexicons that have been associated with a Content-ID can be
+   referenced through the 'session' URI scheme (see Section 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.
+
+   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.
+
+8.6.  SPEAK Method
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 60]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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".
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 61]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+8.7.  STOP
+
+   The STOP method from the client to the server tells the synthesizer
+   resource to stop speaking if it is speaking something.
+
+   The STOP request can be sent with an Active-Request-Id-List header
+   field to stop the zero or more specific SPEAK requests that may be in
+   queue and return a response 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.
+
+   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.
+
+   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.
+
+   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.
+
+   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>
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 62]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+8.8.  BARGE-IN-OCCURRED
+
+   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.
+
+   This method is useful in two scenarios:
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 63]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 64]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+8.9.  PAUSE
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 65]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+8.10.  RESUME
+
+   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.
+
+   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>
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 66]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+8.11.  CONTROL
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 67]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 68]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+8.12.  SPEAK-COMPLETE
+
+   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.
+
+   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>
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 69]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+8.13.  SPEECH-MARKER
+
+   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.
+
+   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/>
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 70]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+                <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
+
+8.14.  DEFINE-LEXICON
+
+   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].
+
+   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".
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 71]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+9.  Speech Recognizer Resource
+
+   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.
+
+   This section applies to the following resource types.
+
+   1.  speechrecog
+
+   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.
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 72]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   Interpretation is accomplished through the INTERPRET method
+   (Section 9.20) and the Interpret-Text header field (Section 9.4.30).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 73]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.1.  Recognizer State Machine
+
+   The recognizer resource maintains a state machine to process MRCPv2
+   requests from the client.
+
+   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.
+
+9.2.  Recognizer Methods
+
+   The recognizer supports the following methods.
+
+   recognizer-method    =  recog-only-method
+                        /  enrollment-method
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 74]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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"
+
+9.3.  Recognizer Events
+
+   The recognizer can generate the following events.
+
+   recognizer-event     =  "START-OF-INPUT"
+                        /  "RECOGNITION-COMPLETE"
+                        /  "INTERPRETATION-COMPLETE"
+
+9.4.  Recognizer Header Fields
+
+   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    =  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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 75]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+                        /  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.
+
+   Note that the Waveform-URI header field of the Recognizer resource
+   can also appear in the response to the END-PHRASE-ENROLLMENT method.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 76]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.1.  Confidence-Threshold
+
+   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     =  "Confidence-Threshold" ":" FLOAT CRLF
+
+9.4.2.  Sensitivity-Level
+
+   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        =  "Sensitivity-Level" ":" FLOAT CRLF
+
+9.4.3.  Speed-Vs-Accuracy
+
+   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
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 77]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   speed-vs-accuracy        =  "Speed-Vs-Accuracy" ":" FLOAT CRLF
+
+9.4.4.  N-Best-List-Length
+
+   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.
+
+   n-best-list-length       =  "N-Best-List-Length" ":" 1*19DIGIT CRLF
+
+9.4.5.  Input-Type
+
+   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.
+
+   input-type         =  "Input-Type" ":"  inputs CRLF
+   inputs             =  "speech" / "dtmf"
+
+9.4.6.  No-Input-Timeout
+
+   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         =  "No-Input-Timeout" ":" 1*19DIGIT CRLF
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 78]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.7.  Recognition-Timeout
+
+   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-timeout      =  "Recognition-Timeout" ":" 1*19DIGIT CRLF
+
+9.4.8.  Waveform-URI
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 79]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.9.  Media-Type
+
+   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.
+
+   media-type               =  "Media-Type" ":" media-type-value
+                               CRLF
+
+9.4.10.  Input-Waveform-URI
+
+   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.
+
+   input-waveform-uri       =  "Input-Waveform-URI" ":" uri CRLF
+
+9.4.11.  Completion-Cause
+
+   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.
+
+   completion-cause         =  "Completion-Cause" ":" cause-code SP
+                               cause-name CRLF
+   cause-code               =  3DIGIT
+   cause-name               =  *VCHAR
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 80]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   +------------+-----------------------+------------------------------+
+   | 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.      |
+   |            |                       |                              |
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 81]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   | 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. |
+   +------------+-----------------------+------------------------------+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 82]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.12.  Completion-Reason
+
+   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.
+
+   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
+
+9.4.13.  Recognizer-Context-Block
+
+   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.
+
+   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.
+
+   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.
+
+   recognizer-context-block  =  "Recognizer-Context-Block" ":"
+                                [1*VCHAR] CRLF
+
+9.4.14.  Start-Input-Timers
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 83]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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".
+
+   start-input-timers  =  "Start-Input-Timers" ":" BOOLEAN CRLF
+
+9.4.15.  Speech-Complete-Timeout
+
+   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-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.
+
+9.4.16.  Speech-Incomplete-Timeout
+
+   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.
+
+   speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*19DIGIT
+                                CRLF
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 84]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+9.4.17.  DTMF-Interdigit-Timeout
+
+   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-interdigit-timeout = "DTMF-Interdigit-Timeout" ":" 1*19DIGIT CRLF
+
+9.4.18.  DTMF-Term-Timeout
+
+   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-term-timeout        =  "DTMF-Term-Timeout" ":" 1*19DIGIT CRLF
+
+9.4.19.  DTMF-Term-Char
+
+   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-term-char           =  "DTMF-Term-Char" ":" VCHAR CRLF
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 85]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.20.  Failed-URI
+
+   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.
+
+   failed-uri               =  "Failed-URI" ":" absoluteURI CRLF
+
+9.4.21.  Failed-URI-Cause
+
+   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.
+
+   failed-uri-cause         =  "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
+
+9.4.22.  Save-Waveform
+
+   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.
+
+   save-waveform            =  "Save-Waveform" ":" BOOLEAN CRLF
+
+9.4.23.  New-Audio-Channel
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 86]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   new-audio-channel        =  "New-Audio-Channel" ":" BOOLEAN
+                               CRLF
+
+9.4.24.  Speech-Language
+
+   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.
+
+   speech-language          =  "Speech-Language" ":" 1*VCHAR CRLF
+
+9.4.25.  Ver-Buffer-Utterance
+
+   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.
+
+9.4.26.  Recognition-Mode
+
+   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
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 87]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   recognition-mode         =  "Recognition-Mode" ":"
+                               "normal" / "hotword" CRLF
+
+9.4.27.  Cancel-If-Queue
+
+   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.
+
+   cancel-if-queue          =  "Cancel-If-Queue" ":" BOOLEAN CRLF
+
+9.4.28.  Hotword-Max-Duration
+
+   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.
+
+   hotword-max-duration     =  "Hotword-Max-Duration" ":" 1*19DIGIT
+                               CRLF
+
+9.4.29.  Hotword-Min-Duration
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 88]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   hotword-min-duration     =  "Hotword-Min-Duration" ":" 1*19DIGIT CRLF
+
+9.4.30.  Interpret-Text
+
+   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.
+
+   interpret-text           =  "Interpret-Text" ":" 1*VCHAR CRLF
+
+9.4.31.  DTMF-Buffer-Time
+
+   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.
+
+   dtmf-buffer-time  =  "DTMF-Buffer-Time" ":" 1*19DIGIT CRLF
+
+9.4.32.  Clear-DTMF-Buffer
+
+   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.
+
+   clear-dtmf-buffer  = "Clear-DTMF-Buffer" ":" BOOLEAN CRLF
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 89]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.33.  Early-No-Match
+
+   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.
+
+   early-no-match  = "Early-No-Match" ":" BOOLEAN CRLF
+
+9.4.34.  Num-Min-Consistent-Pronunciations
+
+   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.
+
+   num-min-consistent-pronunciations  =
+                 "Num-Min-Consistent-Pronunciations" ":" 1*19DIGIT CRLF
+
+9.4.35.  Consistency-Threshold
+
+   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.
+
+   consistency-threshold    =  "Consistency-Threshold" ":" FLOAT CRLF
+
+9.4.36.  Clash-Threshold
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 90]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   clash-threshold          =  "Clash-Threshold" ":" FLOAT CRLF
+
+9.4.37.  Personal-Grammar-URI
+
+   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.
+
+   personal-grammar-uri     =  "Personal-Grammar-URI" ":" uri CRLF
+
+9.4.38.  Enroll-Utterance
+
+   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".
+
+   enroll-utterance     =  "Enroll-Utterance" ":" BOOLEAN CRLF
+
+9.4.39.  Phrase-Id
+
+   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.
+
+   phrase-id                =  "Phrase-ID" ":" 1*VCHAR CRLF
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 91]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.40.  Phrase-NL
+
+   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.
+
+   phrase-nl                =  "Phrase-NL" ":" 1*UTFCHAR CRLF
+
+9.4.41.  Weight
+
+   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.
+
+   weight                   =  "Weight" ":" FLOAT CRLF
+
+9.4.42.  Save-Best-Waveform
+
+   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.
+
+   save-best-waveform  =  "Save-Best-Waveform" ":" BOOLEAN CRLF
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 92]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.4.43.  New-Phrase-Id
+
+   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.
+
+   new-phrase-id            =  "New-Phrase-ID" ":" 1*VCHAR CRLF
+
+9.4.44.  Confusable-Phrases-URI
+
+   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.
+
+   confusable-phrases-uri   =  "Confusable-Phrases-URI" ":" uri CRLF
+
+9.4.45.  Abort-Phrase-Enrollment
+
+   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.
+
+   abort-phrase-enrollment  =  "Abort-Phrase-Enrollment" ":"
+                               BOOLEAN CRLF
+
+9.5.  Recognizer Message Body
+
+   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.
+
+9.5.1.  Recognizer Grammar Data
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 93]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:
+
+   o  the ABNF form (media type 'application/srgs') of SRGS
+
+   o  Sun's 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.
+
+   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.
+
+   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
+
+   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.
+
+   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',
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 94]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   '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.
+
+   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.
+
+   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>
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 95]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+         <!-- 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
+
+
+   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:...
+
+   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:...
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 96]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   <?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--
+
+                      Mixed Grammar Reference Example
+
+9.5.2.  Recognizer Result Data
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 97]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+9.5.3.  Enrollment Result Data
+
+   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.
+
+9.5.4.  Recognizer Context Block
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 98]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+9.6.  Recognizer Results
+
+   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.
+
+9.6.1.  Markup Functions
+
+   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.
+
+   The elements of the markup fall into the following general functional
+   categories: interpretation, side information, and multi-modal
+   integration.
+
+9.6.1.1.  Interpretation
+
+   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:
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                   [Page 99]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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'?"
+
+9.6.1.2.  Side Information
+
+   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>).
+
+   2.  Alternative interpretations (<interpretation>)
+
+   3.  Input formats and Automatic Speech Recognition (ASR) information:
+       the <input> element, representing the input to the semantic
+       interpreter.
+
+9.6.1.3.  Multi-Modal Integration
+
+   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.
+
+9.6.2.  Overview of Recognizer Result Elements and Their Relationships
+
+   The recognizer elements in NLSML fall into two categories:
+
+   1.  description of the input that was processed, and
+
+   2.  description of the meaning which was extracted from the input.
+
+   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,
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 100]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   consider the utterance "OK" (interpreted as "yes").  The example
+   illustrates how that utterance and its interpretation would be
+   represented in the NLSML markup.
+
+   <?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.
+
+9.6.3.  Elements and Attributes
+
+9.6.3.1.  <result> Root Element
+
+   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.
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 101]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   <?xml version="1.0"?>
+   <result xmlns="urn:ietf:params:xml:ns:mrcpv2"
+           grammar="http://www.example.com/grammar">
+     <interpretation>
+      ....
+     </interpretation>
+   </result>
+
+9.6.3.2.  <interpretation> Element
+
+   An <interpretation> element contains a single semantic
+   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.
+
+   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.
+
+   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.
+
+   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 confidence="0.75"
+                   grammar="http://www.example.com/grammar">
+       ...
+   </interpretation>
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 102]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.6.3.3.  <instance> Element
+
+   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.
+
+   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.
+
+   <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
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 103]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.6.3.4.  <input> Element
+
+   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].
+
+   Attributes:
+
+   1.  timestamp-start: The time at which the input began. (optional)
+
+   2.  timestamp-end: The time at which the input ended. (optional)
+
+   3.  mode: The modality of the input, for example, speech, DTMF, etc.
+       (optional)
+
+   4.  confidence: The confidence of the recognizer in the correctness
+       of the input in the range 0.0 to 1.0. (optional)
+
+   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.
+
+   There are three possible formats for the <input> element.
+
+   1.  The <input> element can contain simple text:
+
+       <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.
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 104]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+       <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.
+
+9.6.3.5.  <nomatch> Element
+
+   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.
+
+   <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>
+
+9.6.3.6.  <noinput> Element
+
+   <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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 105]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   <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.
+
+9.7.  Enrollment Results
+
+   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:
+
+   1.  num-clashes
+
+   2.  num-good-repetitions
+
+   3.  num-repetitions-still-needed
+
+   4.  consistency-status
+
+   5.  clash-phrase-ids
+
+   6.  transcriptions
+
+   7.  confusable-phrases
+
+9.7.1.  <num-clashes> Element
+
+   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.
+
+9.7.2.  <num-good-repetitions> Element
+
+   The <num-good-repetitions> element contains the number of consistent
+   pronunciations obtained so far in an active enrollment session.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 106]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.7.3.  <num-repetitions-still-needed> Element
+
+   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.
+
+9.7.4.  <consistency-status> Element
+
+   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.
+
+9.7.5.  <clash-phrase-ids> Element
+
+   The <clash-phrase-ids> element contains the phrase IDs of clashing
+   pronunciation(s), if any.  This element is absent if there are no
+   clashes.
+
+9.7.6.  <transcriptions> Element
+
+   The <transcriptions> element contains the transcriptions returned in
+   the last repetition of the phrase being enrolled.
+
+9.7.7.  <confusable-phrases> Element
+
+   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.
+
+9.8.  DEFINE-GRAMMAR
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 107]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   If the server resource is in the recognition state, the DEFINE-
+   GRAMMAR request MUST respond with a failure status.
+
+   If the resource is in the idle state and is able to successfully
+   process the supplied grammars, the server MUST return a success code
+   status and the request-state MUST be COMPLETE.
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 108]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:...
+
+   <?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"/>
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 109]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+     <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:...
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 110]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:...
+
+   <?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
+
+9.9.  RECOGNIZE
+
+   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.
+
+   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-
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 111]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   code of 407 and a Completion-Cause header field in the response
+   describing the cause of failure.
+
+   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.
+
+   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.
+
+   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.
+
+   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].
+
+   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).
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 112]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 113]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   1.  When the No-Input-Timer expires, the recognizer MUST complete
+       with a Completion-Cause code of "no-input-timeout".
+
+   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".
+
+   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.
+
+   4.  When the Speech-Complete-Timer expires, the recognizer MUST
+       complete with a Completion-Cause code of "success".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 114]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   5.  When the Recognition-Timeout expires, one of the following MUST
+       happen:
+
+       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.2.  If there was a full-match, the recognizer MUST complete
+             with a Completion-Cause code of "success-maxtime".
+
+       5.3.  If there was a no match, the recognizer MUST complete with
+             a Completion-Cause code of "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.
+
+   1.  When the No-Input-Timer expires, the recognizer MUST complete
+       with a Completion-Cause code of "no-input-timeout".
+
+   2.  If at any point a match occurs, the RECOGNIZE MUST complete with
+       a Completion-Cause code of "success".
+
+   3.  When the Recognition-Timeout expires and there is not a match,
+       the RECOGNIZE MUST complete with a Completion-Cause code of
+       "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".
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 115]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:...
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 116]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   <?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.
+
+   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>
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 117]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.10.  STOP
+
+   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".
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 118]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   S->C:   MRCP/2.0 ... 543258 200 COMPLETE
+           Channel-Identifier:32AECB23433801@speechrecog
+           Active-Request-Id-List:543257
+
+9.11.  GET-RESULT
+
+   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.
+
+   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:...
+
+           <?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>
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 119]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+9.12.  START-OF-INPUT
+
+   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.
+
+   This event MUST be generated by the server, irrespective of whether
+   or not the synthesizer and recognizer are on the same server.
+
+9.13.  START-INPUT-TIMERS
+
+   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.
+
+9.14.  RECOGNITION-COMPLETE
+
+   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.
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 120]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 121]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:...
+
+           <?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>
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 122]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+                   <confusable-phrases>
+                        <item>
+                             <phrase> call </phrase>
+                             <confusion-level> 10 </confusion-level>
+                        </item>
+                   </confusable-phrases>
+               </enrollment-result>
+           </result>
+
+9.15.  START-PHRASE-ENROLLMENT
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 123]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+9.16.  ENROLLMENT-ROLLBACK
+
+   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.
+
+   C->S:   MRCP/2.0 ... ENROLLMENT-ROLLBACK 543261
+           Channel-Identifier:32AECB23433801@speechrecog
+
+   S->C:   MRCP/2.0 ... 543261 200 COMPLETE
+           Channel-Identifier:32AECB23433801@speechrecog
+
+9.17.  END-PHRASE-ENROLLMENT
+
+   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.
+
+   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.
+
+  C->S:   MRCP/2.0 ... END-PHRASE-ENROLLMENT 543262
+          Channel-Identifier:32AECB23433801@speechrecog
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 124]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+  S->C:   MRCP/2.0 ... 543262 200 COMPLETE
+          Channel-Identifier:32AECB23433801@speechrecog
+          Waveform-URI:<http://mediaserver.com/recordings/file1324.wav>;
+                       size=242453;duration=25432
+
+9.18.  MODIFY-PHRASE
+
+   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.
+
+   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
+
+9.19.  DELETE-PHRASE
+
+   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.
+
+   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
+
+9.20.  INTERPRET
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 125]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   Recognizer grammar data is treated in the same way as it is when
+   issuing a RECOGNIZE method call.
+
+   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.
+
+   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:...
+
+           <?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
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 126]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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>
+
+9.21.  INTERPRETATION-COMPLETE
+
+   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.
+
+   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.
+
+   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:...
+
+           <?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>
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 127]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+           <!-- 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:...
+
+           <?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>
+
+9.22.  DTMF Detection
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 128]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+10.  Recorder Resource
+
+   This resource captures received audio and video and stores it as
+   content pointed to by a URI.  The main usages of recorders are
+
+   1.  to capture speech audio that may be submitted for recognition at
+       a later time, and
+
+   2.  recording voice or video mails.
+
+   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.
+
+   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.
+
+   See the discussion on the sensitivity of saved waveforms in
+   Section 12.
+
+10.1.  Recorder State Machine
+
+   Idle                   Recording
+   State                  State
+    |                       |
+    |---------RECORD------->|
+    |                       |
+    |<------STOP------------|
+    |                       |
+    |<--RECORD-COMPLETE-----|
+    |                       |
+    |              |--------|
+    |       START-OF-INPUT  |
+    |              |------->|
+    |                       |
+    |              |--------|
+    |    START-INPUT-TIMERS |
+    |              |------->|
+    |                       |
+
+                          Recorder State Machine
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 129]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+10.2.  Recorder Methods
+
+   The recorder resource supports the following methods.
+
+   recorder-method      =  "RECORD"
+                        /  "STOP"
+                        /  "START-INPUT-TIMERS"
+
+10.3.  Recorder Events
+
+   The recorder resource can generate the following events.
+
+   recorder-event       =  "START-OF-INPUT"
+                        /  "RECORD-COMPLETE"
+
+10.4.  Recorder Header Fields
+
+   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
+
+10.4.1.  Sensitivity-Level
+
+   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    =     "Sensitivity-Level" ":" FLOAT CRLF
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 130]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+10.4.2.  No-Input-Timeout
+
+   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.
+
+   no-input-timeout    =     "No-Input-Timeout" ":" 1*19DIGIT CRLF
+
+10.4.3.  Completion-Cause
+
+   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.
+
+   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.              |
+   +------------+-----------------------+------------------------------+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 131]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+10.4.4.  Completion-Reason
+
+   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.
+
+   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
+
+10.4.5.  Failed-URI
+
+   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.
+
+   failed-uri               =  "Failed-URI" ":" absoluteURI CRLF
+
+10.4.6.  Failed-URI-Cause
+
+   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.
+
+   failed-uri-cause         =  "Failed-URI-Cause" ":" 1*UTFCHAR
+                               CRLF
+
+10.4.7.  Record-URI
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 132]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   record-uri               =  "Record-URI" ":" ["<" uri ">"
+                               ";" "size" "=" 1*19DIGIT
+                               ";" "duration" "=" 1*19DIGIT] CRLF
+
+10.4.8.  Media-Type
+
+   A RECORD method MUST contain this header field, which specifies to
+   the server the media type of the captured audio or video.
+
+   media-type               =  "Media-Type" ":" media-type-value
+                               CRLF
+
+10.4.9.  Max-Time
+
+   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.
+
+   max-time                 =  "Max-Time" ":" 1*19DIGIT CRLF
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 133]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+10.4.10.  Trim-Length
+
+   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
+
+10.4.11.  Final-Silence
+
+   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.
+
+   final-silence            =  "Final-Silence" ":" 1*19DIGIT CRLF
+
+10.4.12.  Capture-On-Speech
+
+   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".
+
+   capture-on-speech        =  "Capture-On-Speech " ":" BOOLEAN CRLF
+
+10.4.13.  Ver-Buffer-Utterance
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 134]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+10.4.14.  Start-Input-Timers
+
+   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".
+
+   start-input-timers       =  "Start-Input-Timers" ":"
+                               BOOLEAN CRLF
+
+10.4.15.  New-Audio-Channel
+
+   This header field is the same as the one described for the recognizer
+   resource (see Section 9.4.23).
+
+10.5.  Recorder Message Body
+
+   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.
+
+10.6.  RECORD
+
+   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.
+
+   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.
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 135]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+10.7.  STOP
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 136]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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".
+
+   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
+
+10.8.  RECORD-COMPLETE
+
+   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.
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 137]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+10.9.  START-INPUT-TIMERS
+
+   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.
+
+10.10.  START-OF-INPUT
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 138]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.  Speaker Verification and Identification
+
+   This section describes the methods, responses and events employed by
+   MRCPv2 for doing speaker verification/identification.
+
+   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.
+
+   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).
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 139]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+11.1.  Speaker Verification State Machine
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 140]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+     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      |                         |
+      |<---------|        |                         |
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 141]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+      |                   |----------|              |
+      |                   |    CLEAR-BUFFER         |
+      |                   |<---------|              |
+      |                   |                         |
+      |----------|        |                         |
+      |   CLEAR-BUFFER    |                         |
+      |<---------|        |                         |
+      |                   |                         |
+      |                   |----------|              |
+      |                   |   QUERY-VOICEPRINT      |
+      |                   |<---------|              |
+      |                   |                         |
+      |----------|        |                         |
+      | QUERY-VOICEPRINT  |                         |
+      |<---------|        |                         |
+      |                   |                         |
+      |                   |----------|              |
+      |                   |  DELETE-VOICEPRINT      |
+      |                   |<---------|              |
+      |                   |                         |
+      |----------|        |                         |
+      | DELETE-VOICEPRINT |                         |
+      |<---------|        |                         |
+
+                      Verifier Resource State Machine
+
+11.2.  Speaker Verification Methods
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 142]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   1.  VERIFY-FROM-BUFFER
+
+   The following methods are used for verification of live audio
+   utterances:
+
+   1.  VERIFY
+
+   2.  START-INPUT-TIMERS
+
+   The following methods are used for configuring the verifier resource
+   and for establishing resource states:
+
+   1.  START-SESSION
+
+   2.  END-SESSION
+
+   3.  QUERY-VOICEPRINT
+
+   4.  DELETE-VOICEPRINT
+
+   5.  VERIFY-ROLLBACK
+
+   6.  STOP
+
+   7.  CLEAR-BUFFER
+
+   The following method allows the polling of a verification in progress
+   for intermediate results.
+
+   1.  GET-INTERMEDIATE-RESULT
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 143]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.3.  Verification Events
+
+   The verifier resource generates the following events.
+
+   verifier-event       =  "VERIFICATION-COMPLETE"
+                        /  "START-OF-INPUT"
+
+11.4.  Verification Header Fields
+
+   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
+
+11.4.1.  Repository-URI
+
+   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.
+
+   repository-uri           =  "Repository-URI" ":" uri CRLF
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 144]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.4.2.  Voiceprint-Identifier
+
+   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.
+
+   voiceprint-identifier        =  "Voiceprint-Identifier" ":"
+                                   vid *[";" vid] CRLF
+   vid                          =  1*VCHAR ["." 1*VCHAR]
+
+11.4.3.  Verification-Mode
+
+   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").
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 145]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+   2.  the verification mode has been set to one of "train" or "verify",
+
+   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.
+
+   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"
+
+11.4.4.  Adapt-Model
+
+   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.
+
+   adapt-model              = "Adapt-Model" ":" BOOLEAN CRLF
+
+11.4.5.  Abort-Model
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 146]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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             = "Abort-Model" ":" BOOLEAN CRLF
+
+11.4.6.  Min-Verification-Score
+
+   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  = "Min-Verification-Score" ":"
+                             [ %x2D ] FLOAT CRLF
+
+11.4.7.  Num-Min-Verification-Phrases
+
+   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 =  "Num-Min-Verification-Phrases" ":"
+                                   1*19DIGIT CRLF
+
+11.4.8.  Num-Max-Verification-Phrases
+
+   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" ":"
+                                    1*19DIGIT CRLF
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 147]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.4.9.  No-Input-Timeout
+
+   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         = "No-Input-Timeout" ":" 1*19DIGIT CRLF
+
+11.4.10.  Save-Waveform
+
+   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.
+
+   save-waveform            =  "Save-Waveform" ":" BOOLEAN CRLF
+
+11.4.11.  Media-Type
+
+   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.
+
+   media-type               =  "Media-Type" ":" media-type-value
+                               CRLF
+
+11.4.12.  Waveform-URI
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 148]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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
+
+11.4.13.  Voiceprint-Exists
+
+   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.
+
+   voiceprint-exists    =  "Voiceprint-Exists" ":" BOOLEAN CRLF
+
+11.4.14.  Ver-Buffer-Utterance
+
+   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".
+
+   ver-buffer-utterance     = "Ver-Buffer-Utterance" ":" BOOLEAN
+                              CRLF
+
+11.4.15.  Input-Waveform-URI
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 149]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   input-waveform-uri           =  "Input-Waveform-URI" ":" uri CRLF
+
+11.4.16.  Completion-Cause
+
+   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.
+
+   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.          |
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 150]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   | 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.)                     |
+   +------------+--------------------------+---------------------------+
+
+11.4.17.  Completion-Reason
+
+   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.
+
+   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
+
+11.4.18.  Speech-Complete-Timeout
+
+   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.
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 151]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.4.19.  New-Audio-Channel
+
+   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.
+
+11.4.20.  Abort-Verification
+
+   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.
+
+   abort-verification   =  "Abort-Verification " ":" BOOLEAN CRLF
+
+11.4.21.  Start-Input-Timers
+
+   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".
+
+   start-input-timers       =  "Start-Input-Timers" ":"
+                               BOOLEAN CRLF
+
+11.5.  Verification Message Body
+
+   A verification response or event message can carry additional data as
+   described in the following subsection.
+
+11.5.1.  Verification Result Data
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 152]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.5.2.  Verification Result Elements
+
+   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:
+
+   1.   <voiceprint>
+
+   2.   <incremental>
+
+   3.   <cumulative>
+
+   4.   <decision>
+
+   5.   <utterance-length>
+
+   6.   <device>
+
+   7.   <gender>
+
+   8.   <adapted>
+
+   9.   <verification-score>
+
+   10.  <vendor-specific-results>
+
+11.5.2.1.  <voiceprint> Element
+
+   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.
+
+11.5.2.2.  <cumulative> Element
+
+   Within each <voiceprint> element there MUST be a <cumulative> element
+   with the cumulative scores of how well multiple utterances matched
+   the voiceprint.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 153]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.5.2.3.  <incremental> Element
+
+   The first <voiceprint> element MAY contain an <incremental> element
+   with the incremental scores of how well the last utterance matched
+   the voiceprint.
+
+11.5.2.4.  <Decision> Element
+
+   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".
+
+11.5.2.5.  <utterance-length> Element
+
+   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.
+
+11.5.2.6.  <device> Element
+
+   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".
+
+11.5.2.7.  <gender> Element
+
+   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".
+
+11.5.2.8.  <adapted> Element
+
+   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".
+
+11.5.2.9.  <verification-score> Element
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 154]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+11.5.2.10.  <vendor-specific-results> Element
+
+   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.
+
+   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.
+
+   <?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>
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 155]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+       <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
+
+   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
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 156]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.6.  START-SESSION
+
+   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.
+
+   Upon completion of the START-SESSION method, the verifier resource
+   MUST have terminated any ongoing verification session and cleared any
+   voiceprint designation.
+
+   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).
+
+   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.
+
+   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.
+
+   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".
+
+   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.
+
+   A verifier resource MUST NOT have more than a single session active
+   at one time.
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 157]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+11.7.  END-SESSION
+
+   The END-SESSION method terminates an ongoing verification session and
+   releases the verification voiceprint resources.  The session may
+   terminate in one of three ways:
+
+   1.  abort - the voiceprint adaptation or creation may be aborted so
+       that the voiceprint remains unchanged (or is not created).
+
+   2.  commit - when terminating a voiceprint training session, the new
+       voiceprint is committed to the repository.
+
+   3.  adapt - an existing voiceprint is modified using a successful
+       verification.
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 158]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.8.  QUERY-VOICEPRINT
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 159]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.9.  DELETE-VOICEPRINT
+
+   The DELETE-VOICEPRINT method removes a voiceprint from a repository.
+   This method MUST carry the Repository-URI and Voiceprint-Identifier
+   header fields.
+
+   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.
+
+   If the corresponding voiceprint does not exist, the DELETE-VOICEPRINT
+   method MUST return a 200 status code.
+
+   The following example demonstrates a DELETE-VOICEPRINT operation to
+   remove a specific 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
+
+11.10.  VERIFY
+
+   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.
+
+   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.
+
+11.11.  VERIFY-FROM-BUFFER
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 160]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   For the VERIFY-FROM-BUFFER method, the server MAY optionally return
+   an IN-PROGRESS response before the VERIFICATION-COMPLETE event.
+
+   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).
+
+   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.
+
+   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
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 161]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 162]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:...
+
+          <?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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 163]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.12.  VERIFY-ROLLBACK
+
+   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.
+
+   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
+
+11.13.  STOP
+
+   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".
+
+   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.
+
+   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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 164]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   The following example assumes a voiceprint identity has already been
+   established.
+
+   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
+
+11.14.  START-INPUT-TIMERS
+
+   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
+
+11.15.  VERIFICATION-COMPLETE
+
+   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.
+
+   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">
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 165]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+                <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>
+
+11.16.  START-OF-INPUT
+
+   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.
+
+   S->C:  MRCP/2.0 ... START-OF-INPUT 543259 IN-PROGRESS
+          Channel-Identifier:32AECB23433801@speakverify
+
+11.17.  CLEAR-BUFFER
+
+   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".
+
+   C->S:  MRCP/2.0 ... CLEAR-BUFFER 543260
+          Channel-Identifier:32AECB23433801@speakverify
+
+   S->C:  MRCP/2.0 ... 543260 200 COMPLETE
+          Channel-Identifier:32AECB23433801@speakverify
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 166]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+11.18.  GET-INTERMEDIATE-RESULT
+
+   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.
+
+   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:...
+
+          <?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>
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 167]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+12.  Security Considerations
+
+   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.
+
+12.1.  Rendezvous and Session Establishment
+
+   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:
+
+   1.  The SIP implementation in MRCPv2 clients and servers MUST support
+       SIP digest authentication [RFC3261] and SHOULD employ it.
+
+   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.
+
+   3.  If media stream cryptographic keying is done through SDP (e.g.
+       using [RFC4568]), the MRCPv2 clients and servers MUST employ the
+       '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].
+
+12.2.  Control Channel Protection
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 168]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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]).
+
+12.3.  Media Session Protection
+
+   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].
+
+12.4.  Indirect Content Access
+
+   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.
+
+   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.
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 169]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+12.5.  Protection of Stored Media
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 170]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+12.6.  DTMF and Recognition Buffers
+
+   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.
+
+12.7.  Client-Set Server Parameters
+
+   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.
+
+12.8.  DELETE-VOICEPRINT and Authorization
+
+   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.
+
+13.  IANA Considerations
+
+13.1.  New Registries
+
+   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].
+
+13.1.1.  MRCPv2 Resource Types
+
+   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:
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 171]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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]
+
+13.1.2.  MRCPv2 Methods and Events
+
+   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.
+
+   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]
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 172]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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]
+
+13.1.3.  MRCPv2 Header Fields
+
+   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.
+
+   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]
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 173]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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]
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 174]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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]
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 175]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+13.1.4.  MRCPv2 Status Codes
+
+   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.
+
+13.1.5.  Grammar Reference List Parameters
+
+   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.
+
+   Name                       Reference
+   ----                       -------------
+   weight                     [RFC6787]
+
+13.1.6.  MRCPv2 Vendor-Specific Parameters
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 176]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+13.2.  NLSML-Related Registrations
+
+13.2.1.  'application/nlsml+xml' Media Type Registration
+
+   IANA has registered the following media type according to the process
+   defined in RFC 4288 [RFC4288].
+
+   To:  ietf-types@iana.org
+
+   Subject:  Registration of media type application/nlsml+xml
+
+   MIME media type name:  application
+
+   MIME subtype name:  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.
+
+   Encoding considerations:  All of the considerations described in RFC
+      3023 also apply to the 'application/nlsml+xml' media type.
+
+   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.
+
+   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.
+
+   Published specification:  RFC 6787
+
+   Applications that use this media type:  MRCPv2 clients and servers
+
+   Additional information:  none
+
+   Magic number(s):  There is no single initial octet sequence that is
+      always present for NLSML files.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 177]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   Person & email address to contact for further information:
+      Sarvi Shanmugham, sarvi@cisco.com
+
+   Intended usage:  This media type is expected to be used only in
+      conjunction with MRCPv2.
+
+13.3.  NLSML XML Schema Registration
+
+   IANA has registered and now maintains the following XML Schema.
+   Information provided follows the template in RFC 3688 [RFC3688].
+
+   XML element type:  schema
+
+   URI:  urn:ietf:params:xml:schema:nlsml
+
+   Registrant Contact:  IESG
+
+   XML:  See Section 16.1.
+
+13.4.  MRCPv2 XML Namespace Registration
+
+   IANA has registered and now maintains the following XML Name space.
+   Information provided follows the template in RFC 3688 [RFC3688].
+
+   XML element type:  ns
+
+   URI:  urn:ietf:params:xml:ns:mrcpv2
+
+   Registrant Contact:  IESG
+
+   XML:  RFC 6787
+
+13.5.  Text Media Type Registrations
+
+   IANA has registered the following text media type according to the
+   process defined in RFC 4288 [RFC4288].
+
+13.5.1.  text/grammar-ref-list
+
+   To:  ietf-types@iana.org
+
+   Subject:  Registration of media type text/grammar-ref-list
+
+   MIME media type name:  text
+
+   MIME subtype name:  text/grammar-ref-list
+
+   Required parameters:  none
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 178]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   Interoperability considerations:  '>' must be percent encoded in URIs
+      according to RFC 3986 [RFC3986].
+
+   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:
+
+      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:
+
+            <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
+
+   Additional information:  none
+
+   Magic number(s):  none
+
+   Person & email address to contact for further information:
+      Sarvi Shanmugham, sarvi@cisco.com
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 179]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   Intended usage:  This media type is expected to be used only in
+      conjunction with MRCPv2.
+
+13.6.  'session' URI Scheme Registration
+
+   IANA has registered the following new URI scheme.  The information
+   below follows the template given in RFC 4395 [RFC4395].
+
+   URI scheme name:  session
+
+   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 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.
+
+   Encoding considerations:  There are no other encoding considerations
+      for the 'session' URIs not described in RFC 3986 [RFC3986]
+
+   Applications/protocols that use this URI scheme name:  This scheme
+      name is used by MRCPv2 clients and servers.
+
+   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).
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 180]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+      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.
+
+   Contact:  Sarvi Shanmugham, sarvi@cisco.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.
+
+13.7.  SDP Parameter Registrations
+
+   IANA has registered the following SDP parameter values.  The
+   information for each follows the template given in RFC 4566
+   [RFC4566], Appendix B.
+
+13.7.1.  Sub-Registry "proto"
+
+   "TCP/MRCPv2" value of the "proto" parameter
+
+   Contact name, email address, and telephone number:  Sarvi Shanmugham,
+      sarvi@cisco.com, +1.408.902.3875
+
+   Name being registered (as it will appear in SDP):  TCP/MRCPv2
+
+   Long-form name in English:  MCRPv2 over TCP
+
+   Type of name:  proto
+
+   Explanation of name:  This name represents the MCRPv2 protocol
+      carried over TCP.
+
+   Reference to specification of name:  RFC 6787
+
+   "TCP/TLS/MRCPv2" value of the "proto" parameter
+
+   Contact name, email address, and telephone number:  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
+
+   Type of name:  proto
+
+   Explanation of name:  This name represents the MCRPv2 protocol
+      carried over TLS over TCP.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 181]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   Reference to specification of name:  RFC 6787
+
+13.7.2.  Sub-Registry "att-field (media-level)"
+
+   "resource" value of the "att-field" parameter
+
+   Contact name, email address, and telephone number:  Sarvi Shanmugham,
+      sarvi@cisco.com, +1.408.902.3875
+
+   Attribute name (as it will appear in SDP):  resource
+
+   Long-form attribute name in English:  MRCPv2 resource type
+
+   Type of attribute:  media-level
+
+   Subject to charset attribute?  no
+
+   Explanation of attribute:  See Section 4.2 of RFC 6787 for
+      description and examples.
+
+   Specification of appropriate attribute values:  See section
+      Section 13.1.1 of RFC 6787.
+
+   "channel" value of the "att-field" parameter
+
+   Contact name, email address, and telephone number:  Sarvi Shanmugham,
+      sarvi@cisco.com, +1.408.902.3875
+
+   Attribute name (as it will appear in SDP):  channel
+
+   Long-form attribute name in English:  MRCPv2 resource channel
+      identifier
+
+   Type of attribute:  media-level
+
+   Subject to charset attribute?  no
+
+   Explanation of attribute:  See Section 4.2 of RFC 6787 for
+      description and examples.
+
+   Specification of appropriate attribute values:  See Section 4.2 and
+      the "channel-id" ABNF production rules of RFC 6787.
+
+   "cmid" value of the "att-field" parameter
+
+   Contact name, email address, and telephone number:  Sarvi Shanmugham,
+      sarvi@cisco.com, +1.408.902.3875
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 182]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   Attribute name (as it will appear in SDP):  cmid
+
+   Long-form attribute name in English:  MRCPv2 resource channel media
+      identifier
+
+   Type of attribute:  media-level
+
+   Subject to charset attribute?  no
+
+   Explanation of attribute:  See Section 4.4 of RFC 6787 for
+      description and examples.
+
+   Specification of appropriate attribute values:  See Section 4.4 and
+      the "cmid-attribute" ABNF production rules of RFC 6787.
+
+14.  Examples
+
+14.1.  Message Flow
+
+   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.
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 183]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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:...
+
+          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
+
+   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.
+
+   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:...
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 184]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          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:...
+
+          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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 185]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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:...
+
+          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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 186]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          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:...
+
+          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
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 187]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 188]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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:...
+
+          <?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.
+
+   C->S:  MRCP/2.0 ... SPEAK 543259
+          Channel-Identifier:32AECB23433801@speechsynth
+          Kill-On-Barge-In:true
+          Content-Type:application/ssml+xml
+          Content-Length:...
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 189]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+          <?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.
+
+   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.
+
+   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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 190]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 191]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+14.2.  Recognition Result Examples
+
+14.2.1.  Simple ASR Ambiguity
+
+   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>
+
+14.2.2.  Mixed Initiative
+
+   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.
+
+   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".
+
+   <?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">
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 192]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+     <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>
+
+14.2.3.  DTMF Input
+
+   A combination of DTMF input and speech is represented using nested
+   input elements.  For example:
+   User: My pin is (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>
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 193]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.
+
+14.2.4.  Interpreting Meta-Dialog and Meta-Task Utterances
+
+   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.
+
+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>
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 194]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+14.2.5.  Anaphora and Deixis
+
+   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).
+
+   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>
+
+14.2.6.  Distinguishing Individual Items from Sets with One Member
+
+   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.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 195]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   <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.
+
+   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.
+
+14.2.7.  Extensibility
+
+   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.
+
+15.  ABNF Normative Definition
+
+   The following productions make use of the core rules defined in
+   Section B.1 of RFC 5234 [RFC5234].
+
+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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 196]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+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
+
+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
+
+rel-path         =    rel-segment [ abs-path ]
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 197]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+rel-segment      =    1*( unreserved / escaped / ";" / "@"
+                 /    "&" / "=" / "+" / "$" / "," )
+
+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 ]
+
+host             =    hostname / IPv4address / IPv6reference
+
+hostname         =    *( domainlabel "." ) toplabel [ "." ]
+
+domainlabel      =    alphanum / alphanum *( alphanum / "-" )
+                      alphanum
+
+toplabel         =    ALPHA / ALPHA *( alphanum / "-" )
+                      alphanum
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 198]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+IPv4address      =    1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "."
+                      1*3DIGIT
+
+IPv6reference    =    "[" IPv6address "]"
+
+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  =    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
+
+response-line    =    mrcp-version SP message-length SP request-id
+                      SP status-code 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"
+
+request-state    =    "COMPLETE"
+                 /    "IN-PROGRESS"
+                 /    "PENDING"
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 199]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+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
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 200]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+channel-identifier =  "Channel-Identifier" ":"
+                      channel-id CRLF
+
+channel-id       =    1*alphanum "@" 1*alphanum
+
+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-length   =    "Content-Length" ":" 1*19DIGIT 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
+
+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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 201]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+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-av-pair = vendor-av-pair-name "="
+                          value
+
+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
+
+synthesizer-method    =    "SPEAK"
+                      /    "STOP"
+                      /    "PAUSE"
+                      /    "RESUME"
+                      /    "BARGE-IN-OCCURRED"
+                      /    "CONTROL"
+                      /    "DEFINE-LEXICON"
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 202]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+synthesizer-event     =    "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
+
+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
+
+speaker-profile       =    "Speaker-Profile" ":" uri CRLF
+
+completion-cause         =  "Completion-Cause" ":" cause-code SP
+                            cause-name CRLF
+cause-code               =  3DIGIT
+cause-name               =  *VCHAR
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 203]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+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-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-param-name    =    1*VCHAR
+
+prosody-param-value   =    1*VCHAR
+
+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-cause      =    "Failed-URI-Cause" ":" 1*UTFCHAR CRLF
+
+speak-restart         =    "Speak-Restart" ":" BOOLEAN CRLF
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 204]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+speak-length          =    "Speak-Length" ":" positive-length-value
+                           CRLF
+
+positive-length-value   =  positive-speech-length
+                        /  text-speech-length
+
+load-lexicon          =    "Load-Lexicon" ":" BOOLEAN CRLF
+
+lexicon-search-order  =    "Lexicon-Search-Order" ":"
+          "<" absoluteURI ">" *(" " "<" absoluteURI ">") CRLF
+
+; Recognizer ABNF
+
+recognizer-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"
+
+recognizer-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
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 205]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+                      /    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
+
+sensitivity-level     =    "Sensitivity-Level" ":" FLOAT
+                           CRLF
+
+speed-vs-accuracy     =    "Speed-Vs-Accuracy" ":" FLOAT
+                           CRLF
+
+n-best-list-length    =    "N-Best-List-Length" ":" 1*19DIGIT
+                           CRLF
+
+input-type            =    "Input-Type" ":"  inputs CRLF
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 206]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+inputs                =    "speech" / "dtmf"
+
+no-input-timeout      =    "No-Input-Timeout" ":" 1*19DIGIT
+                           CRLF
+
+recognition-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
+
+start-input-timers    =    "Start-Input-Timers" ":"
+                           BOOLEAN CRLF
+
+speech-complete-timeout =  "Speech-Complete-Timeout" ":"
+                           1*19DIGIT CRLF
+
+speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":"
+                            1*19DIGIT CRLF
+
+dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":"
+                          1*19DIGIT CRLF
+
+dtmf-term-timeout     =    "DTMF-Term-Timeout" ":" 1*19DIGIT
+                           CRLF
+
+dtmf-term-char        =    "DTMF-Term-Char" ":" VCHAR CRLF
+
+save-waveform         =    "Save-Waveform" ":" BOOLEAN CRLF
+
+new-audio-channel     =    "New-Audio-Channel" ":"
+                           BOOLEAN CRLF
+
+recognition-mode      =    "Recognition-Mode" ":"
+                           "normal" / "hotword" CRLF
+
+cancel-if-queue       =    "Cancel-If-Queue" ":" BOOLEAN CRLF
+
+hotword-max-duration  =    "Hotword-Max-Duration" ":"
+                           1*19DIGIT CRLF
+
+hotword-min-duration  =    "Hotword-Min-Duration" ":"
+                           1*19DIGIT CRLF
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 207]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+interpret-text        =    "Interpret-Text" ":" 1*VCHAR CRLF
+
+dtmf-buffer-time      =    "DTMF-Buffer-Time" ":" 1*19DIGIT CRLF
+
+clear-dtmf-buffer     =    "Clear-DTMF-Buffer" ":" BOOLEAN CRLF
+
+early-no-match        =    "Early-No-Match" ":" BOOLEAN CRLF
+
+num-min-consistent-pronunciations    =
+    "Num-Min-Consistent-Pronunciations" ":" 1*19DIGIT CRLF
+
+consistency-threshold =    "Consistency-Threshold" ":" FLOAT
+                           CRLF
+
+clash-threshold       =    "Clash-Threshold" ":" FLOAT CRLF
+
+personal-grammar-uri  =    "Personal-Grammar-URI" ":" uri 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
+
+save-best-waveform    =    "Save-Best-Waveform" ":"
+                           BOOLEAN CRLF
+
+new-phrase-id         =    "New-Phrase-ID" ":" 1*VCHAR CRLF
+
+confusable-phrases-uri =   "Confusable-Phrases-URI" ":"
+                           uri CRLF
+
+abort-phrase-enrollment =  "Abort-Phrase-Enrollment" ":"
+                           BOOLEAN CRLF
+
+; Recorder ABNF
+
+recorder-method       =    "RECORD"
+                      /    "STOP"
+                      /    "START-INPUT-TIMERS"
+
+recorder-event        =    "START-OF-INPUT"
+                      /    "RECORD-COMPLETE"
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 208]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+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
+
+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
+
+; Verifier 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"
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 209]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+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
+
+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
+
+abort-model           =    "Abort-Model" ":" BOOLEAN CRLF
+
+min-verification-score  =  "Min-Verification-Score" ":"
+                           [ %x2D ] FLOAT CRLF
+
+num-min-verification-phrases = "Num-Min-Verification-Phrases"
+                               ":" 1*19DIGIT CRLF
+
+num-max-verification-phrases = "Num-Max-Verification-Phrases"
+                               ":" 1*19DIGIT CRLF
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 210]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+voiceprint-exists     =    "Voiceprint-Exists" ":"
+                           BOOLEAN CRLF
+
+ver-buffer-utterance  =    "Ver-Buffer-Utterance" ":"
+                           BOOLEAN CRLF
+
+input-waveform-uri    =    "Input-Waveform-URI" ":" uri CRLF
+
+abort-verification    =    "Abort-Verification " ":"
+                           BOOLEAN CRLF
+
+   The following productions add a new SDP session-level attribute.  See
+   Paragraph 5.
+
+   cmid-attribute     =    "a=cmid:" identification-tag
+
+   identification-tag =    token
+
+16.  XML Schemas
+
+16.1.  NLSML Schema Definition
+
+ <?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">
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 211]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+                 <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>
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 212]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+16.2.  Enrollment Results Schema Definition
+
+   <?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>
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 213]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+               <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>
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 214]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+     <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"/>
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 215]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+           </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>
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 216]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+     <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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 217]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+17.  References
+
+17.1.  Normative References
+
+   [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.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [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.
+
+   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+              Streaming Protocol (RTSP)", RFC 2326, April 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.
+
+   [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.
+
+   [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.
+
+   [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.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 218]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [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.
+
+   [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.
+
+   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
+              Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [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.
+
+   [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.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 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.
+
+   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
+              Languages", BCP 47, RFC 5646, September 2009.
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 219]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
+              Protocol (SDP) Grouping Framework", RFC 5888, 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.
+
+   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
+              April 2011.
+
+   [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-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-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>.
+
+17.2.  Informative References
+
+   [ISO.8601.1988]
+              International Organization for Standardization, "Data
+              elements and interchange formats - Information interchange
+              - Representation of dates and times", ISO Standard 8601,
+              June 1988.
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 220]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   [Q.23]     International Telecommunications Union, "Technical
+              Features of Push-Button Telephone Sets", ITU-T Q.23, 1993.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
+              October 2005.
+
+   [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.
+
+   [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.
+
+   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
+              Registration Procedures for New URI Schemes", BCP 35,
+              RFC 4395, February 2006.
+
+   [RFC4463]  Shanmugham, S., Monaco, P., and B. Eberman, "A Media
+              Resource Control Protocol (MRCP) Developed by Cisco,
+              Nuance, and Speechworks", RFC 4463, April 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.
+
+   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
+              RFC 4960, September 2007.
+
+   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
+              December 2011.
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 221]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   [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-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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 222]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+Appendix A.  Contributors
+
+   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
+
+   EMail:  charles.galles@intervoice.com
+
+
+   Klaus Reifenrath
+   Scansoft, Inc
+   Guldensporenpark 32
+   Building D
+   9820 Merelbeke
+   Belgium
+
+   EMail: klaus.reifenrath@scansoft.com
+
+Appendix B.  Acknowledgements
+
+   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)
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 223]
+
+RFC 6787                         MRCPv2                    November 2012
+
+
+   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.).
+
+   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.
+
+Authors' Addresses
+
+   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
+
+   EMail: sarvi@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burnett & Shanmugham         Standards Track                  [Page 224]
+
-- 
cgit v1.2.3