Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Sun, 24 Jul 2005 23:05:48 -0700

Addressed this with the following.

Allowed No-Input and Recognition timeouts to happen for Hotword mode
recognition as well.
The could still disabled starting the timers during RECOGNIZE with usual
Start-Input-Timers= false header.

START-OF-SPEECH will not be generated for hoteword mode, but the
Recogntion-Timeout will be started when the user does begin speaking. No
change here, just a clarification on when the recognition timeout is
started.

"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. For regular recognition,
this timer is started when a START-OF-SPEECH event is generated by the
resource. When this timer expires and there is a partial match to a
grammar the recognition request completes with a status code of "008
success-maxtime". For a hotword recognition mode, this timer is started
when the user begins speaking or when the START-INPUT-TIMERS method is
received. Note that for Hotword mode recognition the START-OF-SPEECH
event is not generated. When this timer expires in the hotword mode the
recognition request completes with a status code of "003
recognition-timeout". The recognition-timeout header allows the client
to set this timeout value. The value is in milliseconds. The value for
this header ranges from 0 to an implementation specific maximum value.
The default value is 10 seconds. This header MAY occur in RECOGNIZE,
SET-PARAMS or GET-PARAMS."

Sarvi

     -----Original Message-----
     From: Brett Gavagni [mailto:[email-masked]] 
     Sent: Wednesday, May 04, 2005 11:26 AM
     To: Shanmugham, Saravanan
     Cc: Reifenrath, Klaus; [email-masked]; Thomas Gal
     Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition 
     clarification
     
     Hi,
     
     VoiceXML vendors utilizing MRCP for speech resources are 
     dependent on
     "Recognition-Mode: hotword" to support VoiceXML's 
     "bargeintype=hotword". 
     
     It would be consistent to have a MRCP server terminate a 
     recognition request (RECOGNITION-COMPLETE) in the case of 
     a timer that is triggered for a "no-input" or 
     "recognition-timeout" in either recognition modes. 
     
     It would appear inconsistent for a MRCP server to provide 
     timer capability for a "Recognition-Mode: normal" mode 
     ("non-bargein" or a "speech bargein"), and require a 
     VoiceXML vendor to implement their own timers for
     "Recognition-Mode: hotword". 
     
     Preferred Proposal:
     In the case where a MRCP client does not want any timers 
     enabled,  the client can specify a long value for the 
     specific timer to be disabled (ie. 
      -1 or some other token). 
     
     Alternative Proposal:
     Clarification on the behavior of the recognition timers 
     for both recognition modes would be greatly appreciated, 
     including the clarification of the Recognizer State 
     Machine requirement of generating an error response on 
     START-INPUT-TIMERS when "Recognition-Mode: hotword".
     
     Thanks,
     
     Brett Gavagni
     WebSphere Voice Server Development
     http://www-306.ibm.com/software/pervasive/voice_server/
     [email-masked]

     
     "Shanmugham, Saravanan" <[email-masked]>
     05/04/2005 12:33 PM
     
     To
     Brett Gavagni/West Palm Beach/IBM@IBMUS, "Thomas Gal" 
     <[email-masked]> cc <[email-masked]>, "Reifenrath, Klaus" 
     <[email-masked]> Subject
     RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification

     
     Could you propose exact text as to how you like to modify 
     and clarify the use of this field. If that works for most 
     others, I will update the specfication.
     
     Thanks,
     Sarvi 
     
          -----Original Message-----
          From: [email-masked] 
          [mailto:[email-masked]] On Behalf Of Brett Gavagni
          Sent: Friday, April 29, 2005 12:40 PM
          To: Thomas Gal
          Cc: [email-masked]; 'Reifenrath, Klaus'
          Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition 
          clarification
      
          I'll re-iterate the objection; if a client wants the 
          recognition to last for a timeout, then it should be able 
          to specify this condition. 
      
          The current wording in the specification doesn't clearly 
          indicate that a client request to START-INPUT-TIMERS is 
          invalid for Recognition-Mode: 
          hotword.
      
          The Recognizer State Machine should be clearly documented 
          for both distinct recognition mode if the interpretation 
          is expected to be inconsistent.
      
          Inconsistency usually add to the challenge of implementing 
          a specification and facilitating interoperability.
      
          Thanks,
      
          Brett Gavagni
          WebSphere Voice Server Development
          http://www-306.ibm.com/software/pervasive/voice_server/
          [email-masked]

      
          "Thomas Gal" <[email-masked]>
          04/29/2005 02:58 PM
      
          To
          Brett Gavagni/West Palm Beach/IBM@IBMUS, 
     "'Reifenrath, Klaus'" 
          <[email-masked]>
          cc
          <[email-masked]>
          Subject
          RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification

      
                           Hotword mode recognition is specifically 
          the case where there's no timeout and you want to be 
          actively listening. I don't really see any problem. But to 
          be pragmatic......
      
                           Obviously in the case where there is a 
          limit to the time frame in which the client will want that 
          recognition to occur, they can then send a CANCEL which as 
          you point out may leave holes if there are faulty clients.
          This doesn't prevent the server from having it's own set 
          of limits for such things, which should obviously be set 
          in the context of the application. 
          Now
          I wouldn't have a problem with a special hotword mode 
          timeout parameter (or just honoring the other timeout 
          values) to help in that case, but I also don't see why 
          that can't just be an implementation dependant parameter 
          that doesn't need to be specified or investigated in this 
          protocol. Chances are any services/products sold using 
          this protocol will be based on per-port licensing or some 
          other metric which will assure that it's in the best 
          interest of the user to not be wasting recognition 
          resources, as speech recognition is hardware intensive 
          already. The fact remains that having any sort of real 
          timeout value which limits the recognition scope to 
          something short of the complete "speech transaction" (lets 
          say phone call or
          whatever)
          makes it become just a regular old recognition and 
          specifically NOT HOTWORD mode recognition as people define it.
      
          Personally I agree with Klaus that timeout values should 
          be errors in the context of Hotword recognitions.
      
          -Tom

          -----Original Message-----
          From: [email-masked] 
          [mailto:[email-masked]] On Behalf Of Brett Gavagni
          Sent: Friday, April 29, 2005 11:02 AM
          To: Reifenrath, Klaus
          Cc: [email-masked]
          Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition 
          clarification
      
          The following statement is a bit convoluted in the current 
          draft specification w.r.t. hotword mode.
      
          "It does not timeout nor generate a no-match and will 
     complete 
             only for a successful match of grammar." 
      
          The current draft specification doesn't detail that the 
          timeout headers are invalid for a RECOGNIZE request with 
          Recognition-Mode: hotword.
      
          What would justify a server not honoring timeouts if a 
          client has the ability to specify timeout values? 
      
          The hotword statement listed above also raises concerns in 
          terms of a server providing a robust implementation. An 
          implementing server would have to entirely rely on a 
          client to terminate a recognition request where 
      
          a hotword isn't matched. The complete reliance on a client 
          has a whole separate set of issues for a server to 
          facilitate redundancy.
      
          Thanks,
      
          Brett Gavagni
          WebSphere Voice Server Development
          http://www-306.ibm.com/software/pervasive/voice_server/
          [email-masked]

      
          "Reifenrath, Klaus" <[email-masked]>
          04/28/2005 09:59 AM
      
          To
          Brett Gavagni/West Palm Beach/IBM@IBMUS
          cc
          [email-masked]
          Subject
          RE: [Speechsc] MRCPv2 Hotword Mode Recognition clarification

      
          I think the server should return with status code 402 
          (method not valid in 
      
          this state).
      
          Klaus
      
          From: Brett Gavagni [mailto:[email-masked]]
          Sent: Donnerstag, 28. April 2005 15:39
          To: [email-masked]
          Subject: [Speechsc] MRCPv2 Hotword Mode Recognition 
     clarification

          Hi, 
      
          There's room for interpretation in the following section 
          of the current 
          draft of MRCPv2. 
      
          p53 of the draft-ietf-speechsc-mrcpv2-06.txt 
          Hotword Mode Recognition 
             Hotword mode is where the recognizer looks for a 
          specific speech 
             grammar or dtmf sequence and ignores speech or DTMF 
          that does not 
             match. It does not timeout nor generate a no-match and 
          will complete 
             only for a successful match of grammar. 
      
          What response should a server generate for a 
          START-INPUT-TIMERS request, 
          when the current session has a recognition in progress in 
          hotword mode? 
      
          What would justify a server not honoring timeouts if a 
          client has the 
          ability to specify timeout values? 
      
          Thanks,
      
          Brett Gavagni 
          WebSphere Voice Server Development 
          http://www-306.ibm.com/software/pervasive/voice_server/
          [email-masked]

          _______________________________________________
          Speechsc mailing list
          [email-masked]
          https://www1.ietf.org/mailman/listinfo/speechsc

      
          _______________________________________________
          Speechsc mailing list
          [email-masked]
          https://www1.ietf.org/mailman/listinfo/speechsc

_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Brett Gavagni <[email-masked]>
Date: Mon, 25 Jul 2005 10:00:31 -0400

Looks great!

Thanks,

Brett Gavagni 

07/25/2005 02:05 AM

To

Sarvi

     -----Original Message-----
     From: Brett Gavagni [mailto:[email-masked]] 
     Sent: Wednesday, May 04, 2005 11:26 AM
     To: Shanmugham, Saravanan
     Cc: Reifenrath, Klaus; [email-masked]; Thomas Gal
     Subject: RE: [Speechsc] MRCPv2 Hotword Mode Recognition 
     clarification
 
     Hi,

 
 
     Preferred Proposal:
 
     Alternative Proposal:
 
     Thanks,
 
     Brett Gavagni

 
 
     To

 
 
     Thanks,
     Sarvi 
 
          -----Original Message-----

 

          Thanks,
 
          Brett Gavagni

 
 
          To

 

 
          -Tom

          -----Original Message-----

 

 
 
          Thanks,
 
          Brett Gavagni

 
 
          To

 
 
          this state).
 
          Klaus

          Hi, 

 

          Thanks,
 
          Brett Gavagni