Subject: [Speechsc] Queuing in ASR

From: jakki sasidhar <[email-masked]>
Date: Fri, 21 Jul 2006 18:40:09 +0530

Hi,
    MRCP draft-ietf-speechsc-mrcpv2-10 is not clear about the queuing of
RECOGNIZE request at the ASR resource. As per section 9.9, if the server
receives a RECOGNIZE request and the ASR resource is currently active with
another request, then a 200 response with PENDING state will be dispatched
to the client. But once the ASR becomes free and starts serving the queued
request, it needs to indicate this to the client. In the case of TTS, this
is done by using the SPEECH-MARKER event which carries a NULL marker and the
state as IN-PROGRESS. But for ASR, the spec doesnot define any such
mechanism. 
    Also, if there are multiple requests pending at the client side, a STOP
request defined for TTS can carry a list of request ids to specify which all
requests should be stopped. There is no such provision in case of the STOP
of RECOGNIZE requests.
    Any comments on this will be appreciated.
 
Thanks & Regards,
Sasidhar
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: "Dave Burke" <[email-masked]>
Date: Fri, 21 Jul 2006 18:44:43 +0100

Good comments. I had also spotted the problem of notifying PENDING -> IN-PROGRESS for the speechrecog resource. My personal preference is to simply remove the queuing of RECOGNIZE requests as I don't see any worthwhile value to this feature. It will also be quicker than fixing it though that's just a nice side-effect. Any vehement disagreements?

Dave

----- Original Message ----- 
  From: jakki sasidhar 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Friday, July 21, 2006 2:10 PM
  Subject: [Speechsc] Queuing in ASR

  Hi,
      MRCP draft-ietf-speechsc-mrcpv2-10 is not clear about the queuing of RECOGNIZE request at the ASR resource. As per section 9.9, if the server receives a RECOGNIZE request and the ASR resource is currently active with another request, then a 200 response with PENDING state will be dispatched to the client. But once the ASR becomes free and starts serving the queued request, it needs to indicate this to the client. In the case of TTS, this is done by using the SPEECH-MARKER event which carries a NULL marker and the state as IN-PROGRESS. But for ASR, the spec doesnot define any such mechanism. 
      Also, if there are multiple requests pending at the client side, a STOP request defined for TTS can carry a list of request ids to specify which all requests should be stopped. There is no such provision in case of the STOP of RECOGNIZE requests.
      Any comments on this will be appreciated.

  Thanks & Regards,
  Sasidhar

------------------------------------------------------------------------------

---

From: "Reifenrath, Klaus, VF-Group" <[email-masked]>
Date: Fri, 21 Jul 2006 20:30:46 +0200

The queuing for speech recognition resources was introduced in the
context of hotword recognition. Very often you want to start a normal
recognition after a hotword recognition without loosing audio blocks
between the two recognitions. E.g. a hotword recognition is used to
detect the wake-up  ("Computer") and a normal recognition to recognize
the following request ("Please check my inbox!"). If we cannot queue
recognition requests, the recognition resource will miss meaningful
audio blocks, because the client can start the next recognition only
after it received the recognition result. 
 
The START-OF-SPEECH event indicated that the next recognition is
started. 
 
Klaus

________________________________

	From: Dave Burke [mailto:[email-masked]] 
	Sent: Freitag, 21. Juli 2006 19:45
	To: [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Speechsc] Queuing in ASR

	Good comments. I had also spotted the problem of notifying
PENDING -> IN-PROGRESS for the speechrecog resource. My personal
preference is to simply remove the queuing of RECOGNIZE requests as I
don't see any worthwhile value to this feature. It will also be quicker
than fixing it though that's just a nice side-effect. Any vehement
disagreements?
	 
	Dave
	 
	----- Original Message ----- 

		From: jakki sasidhar <mailto:[email-masked]>  
		To: [email-masked] 
		Cc: [email-masked] ; [email-masked] 
		Sent: Friday, July 21, 2006 2:10 PM
		Subject: [Speechsc] Queuing in ASR

		Hi,
		    MRCP draft-ietf-speechsc-mrcpv2-10 is not clear
about the queuing of RECOGNIZE request at the ASR resource. As per
section 9.9, if the server receives a RECOGNIZE request and the ASR
resource is currently active with another request, then a 200 response
with PENDING state will be dispatched to the client. But once the ASR
becomes free and starts serving the queued request, it needs to indicate
this to the client. In the case of TTS, this is done by using the
SPEECH-MARKER event which carries a NULL marker and the state as
IN-PROGRESS. But for ASR, the spec doesnot define any such mechanism. 
		    Also, if there are multiple requests pending at the
client side, a STOP request defined for TTS can carry a list of request
ids to specify which all requests should be stopped. There is no such
provision in case of the STOP of RECOGNIZE requests.
		    Any comments on this will be appreciated.
		 
		Thanks & Regards,
		Sasidhar

________________________________

---

From: "Dave Burke" <[email-masked]>
Date: Fri, 21 Jul 2006 21:45:41 +0100

Thanks for the clarification.

Still a little puzzled as to the features merit. Couldn't you have "Computer please check my inbox" as a hotword phrase and just have a single recognition - especially as you can't make the second recognitions grammar conditional on the first's result? I'm not sure START-OF-SPEECH is so elegant here - e.g. you're not guaranteed it will be generated if the user just says "Computer". Also, START-OF-SPEECH doesn't correspond accurately to the PENDING to IN-PROGRESS transition but rather with a max error of No-Input-Timeout.

Dave
  ----- Original Message ----- 
  From: Reifenrath, Klaus, VF-Group 
  To: Dave Burke ; [email-masked] ; [email-masked] 
  Cc: [email-masked] 
  Sent: Friday, July 21, 2006 7:30 PM
  Subject: RE: [Speechsc] Queuing in ASR

  The queuing for speech recognition resources was introduced in the context of hotword recognition. Very often you want to start a normal recognition after a hotword recognition without loosing audio blocks between the two recognitions. E.g. a hotword recognition is used to detect the wake-up  ("Computer") and a normal recognition to recognize the following request ("Please check my inbox!"). If we cannot queue recognition requests, the recognition resource will miss meaningful audio blocks, because the client can start the next recognition only after it received the recognition result. 

  The START-OF-SPEECH event indicated that the next recognition is started. 

  Klaus

----------------------------------------------------------------------------

    Dave

    ----- Original Message ----- 
      From: jakki sasidhar 
      To: [email-masked] 
      Cc: [email-masked] ; [email-masked] 
      Sent: Friday, July 21, 2006 2:10 PM
      Subject: [Speechsc] Queuing in ASR

      Hi,

      Thanks & Regards,
      Sasidhar

--------------------------------------------------------------------------

---

From: "Bergallo Patrizio" <[email-masked]>
Date: Mon, 24 Jul 2006 12:05:47 +0200

Hi,
 
about this topic Issue 20 (
<https://www.softarmor.com/roundup/speechsc/issue20>
https://www.softarmor.com/roundup/speechsc/issue20) has been raised 13
months ago, but it is unfortunately still in unread status. Anyway, we
proposed a new RECOGNITION-STARTED event, and a similar one for
verification (VERIFICATION-STARTED), that has the same problem.
A part from introducing a new event or re-using an existent one, we
think this kind of signal is still useful.
We are ok to extend the meaning of START-OF-INPUT for this purpose, i.e.
using a new or blank value for Input-type header, that should be similar
to the way used in the synthesizer resource with the SPEECH-MARKER event
with the speech-marker header.
 
Regards,
Patrizio Bergallo & Vittorio Manzone, Loquendo.

-----Original Message-----
From: Dave Burke [mailto:[email-masked]] 
Sent: Friday, July 21, 2006 10:46 PM
To: Reifenrath, Klaus, VF-Group; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Speechsc] Queuing in ASR

Still a little puzzled as to the features merit. Couldn't you have
"Computer please check my inbox" as a hotword phrase and just have a
single recognition - especially as you can't make the second
recognitions grammar conditional on the first's result? I'm not sure
START-OF-SPEECH is so elegant here - e.g. you're not guaranteed it will
be generated if the user just says "Computer". Also, START-OF-SPEECH
doesn't correspond accurately to the PENDING to IN-PROGRESS transition
but rather with a max error of No-Input-Timeout.
 
Dave

----- Original Message ----- 
From: Reifenrath, Klaus, VF-Group <mailto:[email-masked]>

To: Dave Burke <mailto:[email-masked]>  ; [email-masked] ;
[email-masked] 
Cc: [email-masked] 
Sent: Friday, July 21, 2006 7:30 PM
Subject: RE: [Speechsc] Queuing in ASR

 
Klaus

  _____  

Good comments. I had also spotted the problem of notifying PENDING ->
IN-PROGRESS for the speechrecog resource. My personal preference is to
simply remove the queuing of RECOGNIZE requests as I don't see any
worthwhile value to this feature. It will also be quicker than fixing it
though that's just a nice side-effect. Any vehement disagreements?
 
Dave
 
----- Original Message ----- 

From: jakki  <mailto:[email-masked]> sasidhar 
To: [email-masked] 
Cc: [email-masked] ; [email-masked] 
Sent: Friday, July 21, 2006 2:10 PM
Subject: [Speechsc] Queuing in ASR

Hi,
    MRCP draft-ietf-speechsc-mrcpv2-10 is not clear about the queuing of
RECOGNIZE request at the ASR resource. As per section 9.9, if the server
receives a RECOGNIZE request and the ASR resource is currently active
with another request, then a 200 response with PENDING state will be
dispatched to the client. But once the ASR becomes free and starts
serving the queued request, it needs to indicate this to the client. In
the case of TTS, this is done by using the SPEECH-MARKER event which
carries a NULL marker and the state as IN-PROGRESS. But for ASR, the
spec doesnot define any such mechanism. 
    Also, if there are multiple requests pending at the client side, a
STOP request defined for TTS can carry a list of request ids to specify
which all requests should be stopped. There is no such provision in case
of the STOP of RECOGNIZE requests.
    Any comments on this will be appreciated.
 
Thanks & Regards,
Sasidhar

  _____  

  _____  

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to <mailto:[email-masked]>[email-masked]. Thank you<http://www.loquendo.com>www.loquendo.com
================================================
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc