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

From: "Reifenrath, Klaus" <[email-masked]>
Date: Thu, 28 Apr 2005 09:59:33 -0400

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/
(561) 862-2097 T/L (975)   
[email-masked]

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

---

From: Brett Gavagni <[email-masked]>
Date: Fri, 29 Apr 2005 14:02:12 -0400

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.

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 

"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

Klaus

Hi, 

Thanks,

Brett Gavagni

---

From: "Thomas Gal" <[email-masked]>
Date: Fri, 29 Apr 2005 11:58:23 -0700

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

Thanks,

Brett Gavagni 

To

Klaus

Hi, 

Thanks,

Brett Gavagni

---

From: Brett Gavagni <[email-masked]>
Date: Fri, 29 Apr 2005 15:40:19 -0400

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 

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

-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