<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 COMPLETE
8.7. GET-PARAMS
The GET-PARAMS method, from the client to the server, asks the
recognizer resource for its current default parameters, like
sensitivity-level, n-best-list-length, etc. The client can request
specific parameters from the server by sending it one or more empty
parameter headers with no values. The server should then return the
settings for those specific parameters only. When the client does
not send a specific list of empty parameter headers, the recognizer
should return the settings for all parameters. The wild card use can
be very intensive as the number of settable parameters can be large
depending on the vendor. Hence, it is RECOMMENDED that the client
does not use the wildcard GET-PARAMS operation very often.
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