tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4463

 
 
 

A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks

Part 3 of 4, p. 42 to 67
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 42 
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

Top      Up      ToC       Page 43 
8.3.  Recognizer Events

   The recognizer may generate the following events.

     recognizer-event    =    START-OF-SPEECH
                        /    RECOGNITION-COMPLETE

8.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

Top      Up      ToC       Page 44 
     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

Top      Up      ToC       Page 45 
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 CRLF

8.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 CRLF

8.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 CRLF

8.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,

Top      Up      ToC       Page 46 
   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

Top      Up      ToC       Page 47 
       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

Top      Up      ToC       Page 48 
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 CRLF

8.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

Top      Up      ToC       Page 49 
   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.

Top      Up      ToC       Page 50 
     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.

Top      Up      ToC       Page 51 
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 CRLF

8.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 CRLF

8.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.

Top      Up      ToC       Page 52 
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"?>

Top      Up      ToC       Page 53 
       <!-- 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"

Top      Up      ToC       Page 54 
      --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>

Top      Up      ToC       Page 55 
         </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

Top      Up      ToC       Page 56 
   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.

Top      Up      ToC       Page 57 
   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>

Top      Up      ToC       Page 58 
          <!-- 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

Top      Up      ToC       Page 59 
          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>

Top      Up      ToC       Page 60 
               </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.

Top      Up      ToC       Page 61 
   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"?>

Top      Up      ToC       Page 62 
          <!-- 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>

Top      Up      ToC       Page 63 
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

Top      Up      ToC       Page 64 
     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

Top      Up      ToC       Page 65 
   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">

Top      Up      ToC       Page 66 
          <!-- 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>

Top      Up      ToC       Page 67 
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)

Next RFC Part