RFC 4463
A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks
Pages: 86
Informational
Informational
Part 3 of 4 – Pages 42 to 67
8. Speech Recognizer Resource
The speech recognizer resource is capable of receiving an incoming voice stream and providing the client with an interpretation of what was spoken in textual form.8.1. Recognizer State Machine
The recognizer resource is controlled by MRCP requests from the client. Similarly, the resource can respond to these requests or generate asynchronous events to the server to indicate certain conditions during the processing of the stream. Hence, the recognizer maintains states to correlate MRCP requests from the client. The state transitions are described below. Idle Recognizing Recognized State State State | | | |---------RECOGNIZE---->|---RECOGNITION-COMPLETE-->| |<------STOP------------|<-----RECOGNIZE-----------| | | | | | |-----------| | |--------| GET-RESULT | | START-OF-SPEECH | |---------->| |------------| |------->| | | | |----------| | | DEFINE-GRAMMAR | RECOGNITION-START-TIMERS | |<-----------| |<---------| | | | | | | | |-------| | | | STOP | | |<------| | | | | |<-------------------STOP--------------------------| |<-------------------DEFINE-GRAMMAR----------------|8.2. Recognizer Methods
The recognizer supports the following methods. recognizer-method = SET-PARAMS / GET-PARAMS / DEFINE-GRAMMAR / RECOGNIZE / GET-RESULT / RECOGNITION-START-TIMERS / STOP
8.3. Recognizer Events
The recognizer may generate the following events. recognizer-event = START-OF-SPEECH / RECOGNITION-COMPLETE8.4. Recognizer Header Fields
A recognizer message may contain header fields containing request options and information to augment the Method, Response, or Event message it is associated with. recognizer-header = confidence-threshold ; Section 8.4.1 / sensitivity-level ; Section 8.4.2 / speed-vs-accuracy ; Section 8.4.3 / n-best-list-length ; Section 8.4.4 / no-input-timeout ; Section 8.4.5 / recognition-timeout ; Section 8.4.6 / waveform-url ; Section 8.4.7 / completion-cause ; Section 8.4.8 / recognizer-context-block ; Section 8.4.9 / recognizer-start-timers ; Section 8.4.10 / vendor-specific ; Section 8.4.11 / speech-complete-timeout ; Section 8.4.12 / speech-incomplete-timeout; Section 8.4.13 / dtmf-interdigit-timeout ; Section 8.4.14 / dtmf-term-timeout ; Section 8.4.15 / dtmf-term-char ; Section 8.4.16 / fetch-timeout ; Section 8.4.17 / failed-uri ; Section 8.4.18 / failed-uri-cause ; Section 8.4.19 / save-waveform ; Section 8.4.20 / new-audio-channel ; Section 8.4.21 / speech-language ; Section 8.4.22 Parameter Support Methods/Events confidence-threshold MANDATORY SET-PARAMS, RECOGNIZE GET-RESULT sensitivity-level Optional SET-PARAMS, GET-PARAMS, RECOGNIZE speed-vs-accuracy Optional SET-PARAMS, GET-PARAMS, RECOGNIZE n-best-list-length Optional SET-PARAMS, GET-PARAMS, RECOGNIZE, GET-RESULT no-input-timeout MANDATORY SET-PARAMS, GET-PARAMS, RECOGNIZE
recognition-timeout MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE
waveform-url MANDATORY RECOGNITION-COMPLETE
completion-cause MANDATORY DEFINE-GRAMMAR, RECOGNIZE,
RECOGNITON-COMPLETE
recognizer-context-block Optional SET-PARAMS, GET-PARAMS
recognizer-start-timers MANDATORY RECOGNIZE
vendor-specific MANDATORY SET-PARAMS, GET-PARAMS
speech-complete-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
speech-incomplete-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
dtmf-interdigit-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
dtmf-term-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
dtmf-term-char MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE
fetch-timeout MANDATORY SET-PARAMS, GET-PARAMS
RECOGNIZE, DEFINE-GRAMMAR
failed-uri MANDATORY DEFINE-GRAMMAR response,
RECOGNITION-COMPLETE
failed-uri-cause MANDATORY DEFINE-GRAMMAR response,
RECOGNITION-COMPLETE
save-waveform MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE
new-audio-channel MANDATORY RECOGNIZE
speech-language MANDATORY SET-PARAMS, GET-PARAMS,
RECOGNIZE, DEFINE-GRAMMAR
8.4.1. Confidence Threshold
When a recognition resource recognizes or matches a spoken phrase
with some portion of the grammar, it associates a confidence level
with that conclusion. The confidence-threshold parameter tells the
recognizer resource what confidence level should be considered a
successful match. This is an integer from 0-100 indicating the
recognizer's confidence in the recognition. If the recognizer
determines that its confidence in all its recognition results is less
than the confidence threshold, then it MUST return no-match as the
recognition result. This header field MAY occur in RECOGNIZE, SET-
PARAMS, or GET-PARAMS. The default value for this field is platform
specific.
confidence-threshold = "Confidence-Threshold" ":" 1*DIGIT CRLF
8.4.2. Sensitivity Level
To filter out background noise and not mistake it for speech, the recognizer may support a variable level of sound sensitivity. The sensitivity-level parameter allows the client to set this value on the recognizer. This header field MAY occur in RECOGNIZE, SET- PARAMS, or GET-PARAMS. A higher value for this field means higher sensitivity. The default value for this field is platform specific. sensitivity-level = "Sensitivity-Level" ":" 1*DIGIT CRLF8.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 less calls per media server and vice versa. This parameter on the resource can be tuned by the speed-vs-accuracy header. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. A higher value for this field means higher speed. The default value for this field is platform specific. speed-vs-accuracy = "Speed-Vs-Accuracy" ":" 1*DIGIT CRLF8.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 recognition resource will only return the best match above the confidence threshold. The client, by setting this parameter, could ask the recognition resource to send it more than 1 alternative. All alternatives must still be above the confidence-threshold. A value greater than one does not guarantee that the recognizer will send the requested number of alternatives. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS. The minimum value for this field is 1. The default value for this field is 1. n-best-list-length = "N-Best-List-Length" ":" 1*DIGIT CRLF8.4.5. 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 and terminate the recognition operation. The no-input-timeout header field can set this timeout value. The value is in milliseconds. This header field MAY occur in RECOGNIZE,
SET-PARAMS, or GET-PARAMS. The value for this field ranges from 0 to
MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value
for this field is platform specific.
no-input-timeout = "No-Input-Timeout" ":" 1*DIGIT CRLF
8.4.6. 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 parameter field sets this timeout value. The
value is in milliseconds. The value for this field ranges from 0 to
MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value
is 10 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS
or GET-PARAMS.
recognition-timeout = "Recognition-Timeout" ":" 1*DIGIT CRLF
8.4.7. Waveform URL
If the save-waveform header field is set to true, the recognizer MUST
record the incoming audio stream of the recognition into a file and
provide a URI for the client to access it. This header MUST be
present in the RECOGNITION-COMPLETE event if the save-waveform header
field was set to true. The URL value of the header MUST be NULL if
there was some error condition preventing the server from recording.
Otherwise, the URL generated by the server SHOULD be globally unique
across the server and all its recognition sessions. The URL SHOULD
BE available until the session is torn down.
waveform-url = "Waveform-URL" ":" Url CRLF
8.4.8. Completion Cause
This header field MUST be part of a RECOGNITION-COMPLETE event coming
from the recognizer resource to the client. This indicates the
reason behind the RECOGNIZE method completion. This header field
MUST BE sent in the DEFINE-GRAMMAR and RECOGNIZE responses, if they
return with a failure status and a COMPLETE state.
Cause-Code Cause-Name Description
000 success RECOGNIZE completed with a match or
DEFINE-GRAMMAR succeeded in
downloading and compiling the
grammar
001 no-match RECOGNIZE completed, but no match
was found
002 no-input-timeout
RECOGNIZE completed without a match
due to a no-input-timeout
003 recognition-timeout
RECOGNIZE completed without a match
due to a recognition-timeout
004 gram-load-failure
RECOGNIZE failed due grammar load
failure.
005 gram-comp-failure
RECOGNIZE failed due to grammar
compilation failure.
006 error RECOGNIZE request terminated
prematurely due to a recognizer
error.
007 speech-too-early
RECOGNIZE request terminated because
speech was too early.
008 too-much-speech-timeout
RECOGNIZE request terminated because
speech was too long.
009 uri-failure Failure accessing a URI.
010 language-unsupported
Language not supported.
8.4.9. Recognizer Context Block
This parameter MAY BE sent as part of the SET-PARAMS or GET-PARAMS
request. If the GET-PARAMS method contains this header field with no
value, then it is a request to the recognizer to return the
recognizer context block. The response to such a message MAY contain
a recognizer context block as a message entity. If the server
returns a recognizer context block, the response MUST contain this
header field and its value MUST match the content-id of that entity.
If the SET-PARAMS method contains this header field, it MUST contain
a message entity containing the recognizer context data, and a
content-id matching this header field.
This content-id should match the content-id that came with the
context data during the GET-PARAMS operation.
recognizer-context-block = "Recognizer-Context-Block" ":"
1*ALPHA CRLF
8.4.10. Recognition Start Timers
This parameter MAY BE sent as part of the RECOGNIZE request. A value of false tells the recognizer to start recognition, but not to start the no-input timer yet. The recognizer should not start the timers until the client sends a RECOGNITION-START-TIMERS request to the recognizer. This is useful in the scenario when the recognizer and synthesizer engines are not part of the same session. Here, when a kill-on-barge-in prompt is being played, you want the RECOGNIZE request to be simultaneously active so that it can detect and implement kill-on-barge-in. But at the same time, you don't want the recognizer to start the no-input timers until the prompt is finished. The default value is "true". recognizer-start-timers = "Recognizer-Start-Timers" ":" boolean-value CRLF8.4.11. Vendor Specific Parameters
This set of headers allows the client to set Vendor Specific parameters. This header can be sent in the SET-PARAMS method and is used to set vendor-specific parameters on the server. The vendor-av-pair-name can be any vendor-specific field name and conforms to the XML vendor-specific attribute naming convention. The vendor-av-pair- value is the value to set the attribute to, and needs to be quoted. When asking the server to get the current value of these parameters, this header can be sent in the GET-PARAMS method with the list of vendor-specific attribute names to get separated by a semicolon. This header field MAY occur in SET-PARAMS or GET-PARAMS.8.4.12. 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 throwing a nomatch event). The speech-complete- timeout value is used when the recognizer currently has a complete match of an active grammar, and specifies how long it should wait for more input before declaring a match. By contrast, the incomplete timeout is used when the speech is an incomplete match to an active grammar. The value is in milliseconds. speech-complete-timeout = "Speech-Complete-Timeout" ":" 1*DIGIT CRLF
A long speech-complete-timeout value delays the result completion and, therefore, makes the computer's response slow. A short speech- complete-timeout may lead to an utterance being broken up inappropriately. Reasonable complete timeout values are typically in the range of 0.3 seconds to 1.0 seconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.8.4.13. 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 nomatch event). The value is in milliseconds. The value for this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value for this field is platform specific. speech-incomplete-timeout = "Speech-Incomplete-Timeout" ":" 1*DIGIT CRLF The speech-incomplete-timeout also applies when the speech prior to the silence is a complete match of an active grammar, but where it is possible to speak further and still match the grammar. By contrast, the complete timeout is used when the speech is a complete match to an active grammar and no further words can be spoken. A long speech-incomplete-timeout value delays the result completion and, therefore, makes the computer's response slow. A short speech- incomplete-timeout may lead to an utterance being broken up inappropriately. The speech-incomplete-timeout is usually longer than the speech- complete-timeout to allow users to pause mid-utterance (for example, to breathe). This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.8.4.14. 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 field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform specific. The default value is 5 seconds. This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
dtmf-interdigit-timeout = "DTMF-Interdigit-Timeout" ":"
1*DIGIT CRLF
8.4.15. DTMF Term Timeout
This header field specifies the terminating timeout to use when
recognizing DTMF input. The value is in milliseconds. The value for
this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform
specific. The default value is 10 seconds. This header field MAY
occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
dtmf-term-timeout = "DTMF-Term-Timeout" ":" 1*DIGIT CRLF
8.4.16. DTMF-Term-Char
This header field specifies the terminating DTMF character for DTMF
input recognition. The default value is NULL which is specified as
an empty header field. This header field MAY occur in RECOGNIZE,
SET-PARAMS, or GET-PARAMS.
dtmf-term-char = "DTMF-Term-Char" ":" CHAR CRLF
8.4.17. Fetch Timeout
When the recognizer needs to fetch grammar documents, this header
field controls URI access properties. This defines the recognizer
timeout for completing the fetch of the resources the media server
needs from the network. The value is in milliseconds. The value for
this field ranges from 0 to MAXTIMEOUT, where MAXTIMEOUT is platform
specific. The default value for this field is platform specific.
This header field MAY occur in RECOGNIZE, SET-PARAMS, or GET-PARAMS.
8.4.18. Failed URI
When a recognizer method needs a recognizer to fetch or access a URI,
and the access fails, the media server SHOULD provide the failed URI
in this header field in the method response.
8.4.19. Failed URI Cause
When a recognizer method needs a recognizer to fetch or access a URI,
and the access fails, the media server SHOULD provide the URI-
specific or protocol-specific response code through this header field
in the method response. This field has been defined as alphanumeric
to accommodate all protocols, some of which might have a response
string instead of a numeric response code.
8.4.20. Save Waveform
This header field allows the client to indicate to the recognizer that it MUST save the audio stream that was recognized. The recognizer MUST then record the recognized audio and make it available to the client in the form of a URI returned in the waveform-uri header field in the RECOGNITION-COMPLETE event. If there was an error in recording the stream or the audio clip is otherwise not available, the recognizer MUST return an empty waveform-uri header field. The default value for this fields is "false". save-waveform = "Save-Waveform" ":" boolean-value CRLF8.4.21. New Audio Channel
This header field MAY BE specified in a RECOGNIZE message and allows the client to tell the media server that, from that point on, it will be sending audio data from a new audio source, channel, or speaker. If the recognition resource had collected any line statistics or information, it MUST discard it and start fresh for this RECOGNIZE. This helps in the case where the client MAY want to reuse an open recognition session with the media server for multiple telephone calls. new-audio-channel = "New-Audio-Channel" ":" boolean-value CRLF8.4.22. 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 should follow RFC 3066 [16] for its values. This MAY occur in DEFINE-GRAMMAR, RECOGNIZE, SET-PARAMS, or GET-PARAMS request.8.5. Recognizer Message Body
A recognizer message may carry additional data associated with the method, response, or event. The client may send the grammar to be recognized in DEFINE-GRAMMAR or RECOGNIZE requests. When the grammar is sent in the DEFINE-GRAMMAR method, the server should be able to download compile and optimize the grammar. The RECOGNIZE request MUST contain a list of grammars that need to be active during the recognition. The server resource may send the recognition results in the RECOGNITION-COMPLETE event or the GET-RESULT response. This data will be carried in the message body of the corresponding MRCP message.
8.5.1. Recognizer Grammar Data
Recognizer grammar data from the client to the server can be provided inline or by reference. Either way, they are carried as MIME entities in the message body of the MRCP request message. The grammar specified inline or by reference specifies the grammar used to match in the recognition process and this data is specified in one of the standard grammar specification formats like W3C's XML or ABNF or Sun's Java Speech Grammar Format, etc. All media servers MUST support W3C's XML based grammar markup format [11] (MIME-type application/grammar+xml) and SHOULD support the ABNF form (MIME-type application/grammar). When a grammar is specified in-line in the message, the client MUST provide a content-id for that grammar as part of the content headers. The server MUST store the grammar associated with that content-id for the duration of the session. A stored grammar can be overwritten by defining a new grammar with the same content-id. Grammars that have been associated with a content-id can be referenced through a special "session:" URI scheme. Example: session:help@root-level.store If grammar data needs to be specified by external URI reference, the MIME-type text/uri-list is used to list the one or more URI that will specify the grammar data. All media servers MUST support the HTTP URI access mechanism. If the data to be defined consists of a mix of URI and inline grammar data, the multipart/mixed MIME-type is used and embedded with the MIME-blocks for text/uri-list, application/grammar or application/grammar+xml. The character set and encoding used in the grammar data may be specified according to standard MIME-type definitions. When more than one grammar URI or inline grammar block is specified in a message body of the RECOGNIZE request, it is an active list of grammar alternatives to listen. The ordering of the list implies the precedence of the grammars, with the first grammar in the list having the highest precedence. Example 1: Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104 <?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- the equivalent single-language attachment expansion -->
<rule id="people2">
<one-of>
<item xml:lang="en-US">Robert</item>
<item xml:lang="fr-CA">Robert</item>
</one-of>
</rule>
</grammar>
Example 2:
Content-Type:text/uri-list
Content-Length:176
session:help@root-level.store
http://www.cisco.com/Directory-Name-List.grxml
http://www.cisco.com/Department-List.grxml
http://www.cisco.com/TAC-Contact-List.grxml
session:menu1@menu-level.store
Example 3:
Content-Type:multipart/mixed; boundary="--break"
--break
Content-Type:text/uri-list
Content-Length:176
http://www.cisco.com/Directory-Name-List.grxml
http://www.cisco.com/Department-List.grxml
http://www.cisco.com/TAC-Contact-List.grxml
--break
Content-Type:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
<!-- multiple language attachment to a token -->
<rule id="people1">
<token lexicon="en-US,fr-CA"> Robert </token>
</rule>
<!-- the equivalent single-language attachment expansion -->
<rule id="people2">
<one-of>
<item xml:lang="en-US">Robert</item>
<item xml:lang="fr-CA">Robert</item>
</one-of>
</rule>
</grammar>
--break
8.5.2. Recognizer Result Data
Recognition result data from the server is carried in the MRCP
message body of the RECOGNITION-COMPLETE event or the GET-RESULT
response message as MIME entities. All media servers MUST support
W3C's Natural Language Semantics Markup Language (NLSML) [10] as the
default standard for returning recognition results back to the
client, and hence MUST support the MIME-type application/x-nlsml.
Example 1:
Content-Type:application/x-nlsml
Content-Length:104
<?xml version="1.0"?>
<result grammar="http://theYesNoGrammar">
<interpretation>
<instance>
<myApp:yes_no>
<response>yes</response>
</myApp:yes_no>
</instance>
<input>ok</input>
</interpretation>
</result>
8.5.3. Recognizer Context Block
When the client has to change recognition servers within a call, this
is a block of data that the client MAY collect from the first media
server and provide to the second media server. This may be because
the client needs different language support or because the media
server issued an RTSP RE-DIRECT. Here, the first recognizer may have
collected acoustic and other data during its recognition. When we
switch recognition servers, communicating this data may allow the
second recognition server to provide better recognition based on the
acoustic data collected by the previous recognizer. This block of
data is vendor-specific and MUST be carried as MIME-type
application/octets in the body of the message.
This block of data is communicated in the SET-PARAMS and GET-PARAMS
method/response messages. In the GET-PARAMS method, if an empty
recognizer-context-block header field is present, then the recognizer
should return its vendor-specific context block in the message body
as a MIME-entity with a specific content-id. The content-id value
should also be specified in the recognizer-context-block header field
in the GET-PARAMS response. The SET-PARAMS request wishing to provide this vendor-specific data should send it in the message body as a MIME-entity with the same content-id that it received from the GET-PARAMS. The content-id should also be sent in the recognizer- context-block header field of the SET-PARAMS message. Each automatic speech recognition (ASR) vendor choosing to use this mechanism to handoff recognizer context data among its servers should distinguish its vendor-specific block of data from other vendors by choosing a unique content-id that they should recognize.8.6. SET-PARAMS
The SET-PARAMS method, from the client to the server, tells the recognizer resource to set and modify recognizer context parameters like recognizer characteristics, result detail level, etc. In the following sections some standard parameters are discussed. If the server resource does not recognize an OPTIONAL parameter, it MUST ignore that field. Many of the parameters in the SET-PARAMS method can also be used in another method like the RECOGNIZE method. But the difference is that when you set something like the sensitivity- level using the SET-PARAMS, it applies for all future requests, whenever applicable. On the other hand, when you pass sensitivity- level in a RECOGNIZE request, it applies only to that request. Example: C->S:SET-PARAMS 543256 MRCP/1.0 Sensitivity-Level:20 Recognition-Timeout:30 Confidence-Threshold:85 S->C:MRCP/1.0 543256 200 COMPLETE8.7. GET-PARAMS
The GET-PARAMS method, from the client to the server, asks the recognizer resource for its current default parameters, like sensitivity-level, n-best-list-length, etc. The client can request specific parameters from the server by sending it one or more empty parameter headers with no values. The server should then return the settings for those specific parameters only. When the client does not send a specific list of empty parameter headers, the recognizer should return the settings for all parameters. The wild card use can be very intensive as the number of settable parameters can be large depending on the vendor. Hence, it is RECOMMENDED that the client does not use the wildcard GET-PARAMS operation very often.
Example:
C->S:GET-PARAMS 543256 MRCP/1.0
Sensitivity-Level:
Recognition-Timeout:
Confidence-threshold:
S->C:MRCP/1.0 543256 200 COMPLETE
Sensitivity-Level:20
Recognition-Timeout:30
Confidence-Threshold:85
8.8. DEFINE-GRAMMAR
The DEFINE-GRAMMAR method, from the client to the server, provides a
grammar and tells the server to define, download if needed, and
compile the grammar.
If the server resource is in the recognition state, the DEFINE-
GRAMMAR request MUST respond with a failure status.
If the resource is in the idle state and is able to successfully load
and compile the grammar, the status MUST return a success code and
the request-state MUST be COMPLETE.
If the recognizer could not define the grammar for some reason, say
the download failed or the grammar failed to compile, or the grammar
was in an unsupported form, the MRCP response for the DEFINE-GRAMMAR
method MUST contain a failure status code of 407, and a completion-
cause header field describing the failure reason.
Example:
C->S:DEFINE-GRAMMAR 543257 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/1.0 543257 200 COMPLETE
Completion-Cause:000 success
C->S:DEFINE-GRAMMAR 543258 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:helpgrammar@root-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
</grammar>
S->C:MRCP/1.0 543258 200 COMPLETE
Completion-Cause:000 success
C->S:DEFINE-GRAMMAR 543259 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:request2@field-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<rule id="request">
I need help
</rule>
S->C:MRCP/1.0 543258 200 COMPLETE
Completion-Cause:000 success
C->S:DEFINE-GRAMMAR 543259 MRCP/1.0
Content-Type:application/grammar+xml
Content-Id:request2@field-level.store
Content-Length:104
<?xml version="1.0"?>
<grammar xml:lang="en">
<import uri="session:politeness@form-level.store"
name="polite"/>
<rule id="basicCmd" scope="public">
<example> please move the window </example>
<example> open a file </example>
<ruleref import="polite#startPolite"/>
<ruleref uri="#command"/>
<ruleref import="polite#endPolite"/>
</rule>
<rule id="command">
<ruleref uri="#action"/> <ruleref uri="#object"/>
</rule>
<rule id="action">
<choice>
<item weight="10" tag="OPEN"> open </item>
<item weight="2" tag="CLOSE"> close </item>
<item weight="1" tag="DELETE"> delete </item>
<item weight="1" tag="MOVE"> move </item>
</choice>
</rule>
<rule id="object">
<count number="optional">
<choice>
<item> the </item>
<item> a </item>
</choice>
</count>
<choice>
<item> window </item>
<item> file </item>
<item> menu </item>
</choice>
</rule>
</grammar>
S->C:MRCP/1.0 543259 200 COMPLETE
Completion-Cause:000 success
C->S:RECOGNIZE 543260 MRCP/1.0
N-Best-List-Length:2
Content-Type:text/uri-list
Content-Length:176
session:request1@form-level.store
session:request2@field-level.store
session:helpgramar@root-level.store
S->C:MRCP/1.0 543260 200 IN-PROGRESS
S->C:START-OF-SPEECH 543260 IN-PROGRESS MRCP/1.0
S->C:RECOGNITION-COMPLETE 543260 COMPLETE MRCP/1.0
Completion-Cause:000 success
Waveform-URL:http://web.media.com/session123/audio.wav
Content-Type:applicationt/x-nlsml
Content-Length:276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
8.9. RECOGNIZE
The RECOGNIZE method from the client to the server tells the
recognizer to start recognition and provides it with a grammar to
match for. The RECOGNIZE method can carry parameters to control the
sensitivity, confidence level, and the level of detail in results
provided by the recognizer. These parameters override the current
defaults set by a previous SET-PARAMS method.
If the resource is in the recognition state, the RECOGNIZE request
MUST respond with a failure status.
If the resource is in the Idle state and was able to successfully
start the recognition, the server MUST return a success code and a
request-state of IN-PROGRESS. This means that the recognizer is
active and that the client should expect further events with this
request-id.
If the resource could not start a recognition, it MUST return a
failure status code of 407 and contain a completion-cause header
field describing the cause of failure.
For the recognizer resource, this is the only request that can return
request-state of IN-PROGRESS, meaning that recognition is in
progress. When the recognition completes by matching one of the
grammar alternatives or by a time-out without a match or for some
other reason, the recognizer resource MUST send the client a
RECOGNITON-COMPLETE event with the result of the recognition and a
request-state of COMPLETE.
For large grammars that can take a long time to compile and for
grammars that are used repeatedly, the client could issue a DEFINE-
GRAMMAR request with the grammar ahead of time. In such a case, the
client can issue the RECOGNIZE request and reference the grammar
through the "session:" special URI. This also applies in general if
the client wants to restart recognition with a previous inline
grammar.
Note that since the audio and the messages are carried over separate
communication paths there may be a race condition between the start
of the flow of audio and the receipt of the RECOGNIZE method. For
example, if audio flow is started by the client at the same time as
the RECOGNIZE method is sent, either the audio or the RECOGNIZE will
arrive at the recognizer first. As another example, the client may
chose to continuously send audio to the Media server and signal the
Media server to recognize using the RECOGNIZE method. A number of
mechanisms exist to resolve this condition and the mechanism chosen
is left to the implementers of recognizer Media servers.
Example:
C->S:RECOGNIZE 543257 MRCP/1.0
Confidence-Threshold:90
Content-Type:application/grammar+xml
Content-Id:request1@form-level.store
Content-Length:104
<?xml version="1.0"?>
<!-- the default grammar language is US English -->
<grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0
Completion-Cause:000 success
Waveform-URL:http://web.media.com/session123/audio.wav
Content-Type:application/x-nlsml
Content-Length:276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
8.10. STOP
The STOP method from the client to the server tells the resource to stop recognition if one is active. If a RECOGNIZE request is active and the STOP request successfully terminated it, then the response header contains an active-request-id-list header field containing the request-id of the RECOGNIZE request that was terminated. In this case, no RECOGNITION-COMPLETE event will be sent for the terminated request. If there was no recognition active, then the response MUST NOT contain an active-request-id-list header field. Either way,method the response MUST contain a status of 200(Success). Example: C->S:RECOGNIZE 543257 MRCP/1.0 Confidence-Threshold:90 Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104 <?xml version="1.0"?> <!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0"> <!-- single language attachment to tokens --> <rule id="yes"> <one-of> <item xml:lang="fr-CA">oui</item> <item xml:lang="en-US">yes</item> </one-of> </rule> <!-- single language attachment to a rule expansion --> <rule id="request"> may I speak to <one-of xml:lang="fr-CA"> <item>Michel Tremblay</item> <item>Andre Roy</item> </one-of> </rule> </grammar> S->C:MRCP/1.0 543257 200 IN-PROGRESS C->S:STOP 543258 200 MRCP/1.0
S->C:MRCP/1.0 543258 200 COMPLETE
Active-Request-Id-List:543257
8.11. GET-RESULT
The GET-RESULT method from the client to the server can be issued
when the recognizer is in the recognized state. This request allows
the client to retrieve results for a completed recognition. This is
useful if the client decides it wants more alternatives or more
information. When the media server receives this request, it should
re-compute and return the results according to the recognition
constraints provided in the GET-RESULT request.
The GET-RESULT request could specify constraints like a different
confidence-threshold, or n-best-list-length. This feature is
optional and the automatic speech recognition (ASR) engine may return
a status of unsupported feature.
Example:
C->S:GET-RESULT 543257 MRCP/1.0
Confidence-Threshold:90
S->C:MRCP/1.0 543257 200 COMPLETE
Content-Type:application/x-nlsml
Content-Length:276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
8.12. START-OF-SPEECH
This is an event from the recognizer to the client indicating that it
has detected speech. This event is useful in implementing kill-on-
barge-in scenarios when the synthesizer resource is in a different
session than the recognizer resource and, hence, is not aware of an
incoming audio source. In these cases, it is up to the client to act
as a proxy and turn around and issue the BARGE-IN-OCCURRED method to the synthesizer resource. The recognizer resource also sends a unique proxy-sync-id in the header for this event, which is sent to the synthesizer in the BARGE-IN-OCCURRED method to the synthesizer. This event should be generated irrespective of whether the synthesizer and recognizer are in the same media server or not.8.13. RECOGNITION-START-TIMERS
This request is sent from the client to the recognition resource when it knows that a kill-on-barge-in prompt has finished playing. This is useful in the scenario when the recognition and synthesizer engines are not in the same session. Here, when a kill-on-barge-in prompt is being played, you want the RECOGNIZE request to be simultaneously active so that it can detect and implement kill-on- barge-in. But at the same time, you don't want the recognizer to start the no-input timers until the prompt is finished. The parameter recognizer-start-timers header field in the RECOGNIZE request will allow the client to say if the timers should be started or not. The recognizer should not start the timers until the client sends a RECOGNITION-START-TIMERS method to the recognizer.8.14. RECOGNITON-COMPLETE
This is an Event from the recognizer resource to the client indicating that the recognition completed. The recognition result is sent in the MRCP body of the message. The request-state field MUST be COMPLETE indicating that this is the last event with that request-id, and that the request with that request-id is now complete. The recognizer context still holds the results and the audio waveform input of that recognition until the next RECOGNIZE request is issued. A URL to the audio waveform MAY BE returned to the client in a waveform-url header field in the RECOGNITION-COMPLETE event. The client can use this URI to retrieve or playback the audio. Example: C->S:RECOGNIZE 543257 MRCP/1.0 Confidence-Threshold:90 Content-Type:application/grammar+xml Content-Id:request1@form-level.store Content-Length:104 <?xml version="1.0"?> <!-- the default grammar language is US English --> <grammar xml:lang="en-US" version="1.0">
<!-- single language attachment to tokens -->
<rule id="yes">
<one-of>
<item xml:lang="fr-CA">oui</item>
<item xml:lang="en-US">yes</item>
</one-of>
</rule>
<!-- single language attachment to a rule expansion -->
<rule id="request">
may I speak to
<one-of xml:lang="fr-CA">
<item>Michel Tremblay</item>
<item>Andre Roy</item>
</one-of>
</rule>
</grammar>
S->C:MRCP/1.0 543257 200 IN-PROGRESS
S->C:START-OF-SPEECH 543257 IN-PROGRESS MRCP/1.0
S->C:RECOGNITION-COMPLETE 543257 COMPLETE MRCP/1.0
Completion-Cause:000 success
Waveform-URL:http://web.media.com/session123/audio.wav
Content-Type:application/x-nlsml
Content-Length:276
<?xml version="1.0"?>
<result x-model="http://IdentityModel"
xmlns:xf="http://www.w3.org/2000/xforms"
grammar="session:request1@form-level.store">
<interpretation>
<xf:instance name="Person">
<Person>
<Name> Andre Roy </Name>
</Person>
</xf:instance>
<input> may I speak to Andre Roy </input>
</interpretation>
</result>
8.15. DTMF Detection
Digits received as DTMF tones will be delivered to the automatic speech recognition (ASR) engine in the RTP stream according to RFC 2833 [15]. The automatic speech recognizer (ASR) needs to support RFC 2833 [15] to recognize digits. If it does not support RFC 2833 [15], it will have to process the audio stream and extract the audio tones from it.
(page 67 continued on part 4)