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

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 4 May 2005 09:33:59 -0700

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: Wed, 4 May 2005 14:26:03 -0400

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 

"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

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

 

     Thanks,
 
     Brett Gavagni

 
 
     To

 

 
     -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

 

 
 
     Thanks,
 
     Brett Gavagni

 
 
     To

 
 
     this state).
 
     Klaus

     Hi, 

 

     Thanks,
 
     Brett Gavagni