Subject: RE: [Speechsc] Hotword Recognitions

From: "Pierre Forgues" <[email-masked]>
Date: Mon, 29 Mar 2004 07:20:58 -0500

I agree with (1).  A Hotword recognition should just return recognition
complete when the Hotword phrase matched.  /Pierre
 
-----Original Message-----
From: Alex Lee [mailto:[email-masked]] 
Sent: 25 mars, 2004 18:09
Cc: [email-masked]
Subject: [Speechsc] Hotword Recognitions
 
For the "hotword recognitions", what should the semantics be for the
START-OF-SPEECH event that comes back from the recognizer to the client.
There seems to be 4 different approaches here: 
1) There shouldn't be any START-OF-SPEECH event to be sent back from
recognizer 
2) The START-OF-SPEECH event should be sent back when the recognizer
first detects speech, whether the speech matches the hotword parameter
and grammar or not.  If the speech doesn't match the grammar, nothing
further would be sent from the recognizer.  After a while the speaker
stops and starts speaking again and matches the grammar, then the
RECOGNITION-COMPLETE would be sent.  However, there won't be any more
START-OF-SPEECH for the other times the recognizer detects speech. 
3) The START-OF-SPEECH event should be sent back to the client just
before the RECOGNITION-COMPLETE event. 
4) There should be multiple START-OF-SPEECH event sent back from the
server to the client, where each time the recognizer detects speech, it
will send the START-OF-SPEECH event back to the client. 
To me, I think (1) would be the correct behaviour, because a
"START-OF-SPEECH" event doesn't really make sense for hotword mode.  My
second choice would be (4). 
Any suggestions? 
Alex... 
Jeff Kusnitz wrote: 
	  
	Dan Burnett wrote on 03/03/2004 06:35:34 AM: 
	> Eric, 
	> 
	> Thanks for sending the minutes.  Please accept my apologies
again 
	> for not being able to attend. 
	> 
	> I have a question about your "speech vs hotword barge-in"
topic. 
	> "speech" and "hotword" are recognition types distinguished by
what 
	> happens on a rejection (failure to match the speech to a
grammar 
	> path).  Barge-in refers to whether or not a recognizer listens
for 
	> speech while a prompt is playing.  My understanding is that
these 
	> features are orthogonal.  Can you explain the question here? 
	If I'm not mistaken (I also was not able to attend), the "speech
vs hotword barge-in" request came from me - it was a request for a
header that would map to the VoiceXML bargeintype attribute - when set
to "speech", the recognition engine would send a bargein message to the
client/tts engine immediately, but when set to "hotword", the bargein
message would only be sent in the event of a successful recognition. 
	Thanks, 
	Jeff
_______________________________________________ Speechsc mailing list
[email-masked] https://www1.ietf.org/mailman/listinfo/speechsc