Subject: [Speechsc] MRCPv2 clarification

From: "Pierre Forgues" <[email-masked]>
Date: Tue, 7 Jun 2005 08:12:17 -0400

Section 9 of the MRCPv2 specification includes the following sentence:
"The recognition resource may support recognition in the normal or
hotword modes or both."  I'm not sure the same recognition resource can
support "both" because the state machinery does not allow two concurrent
recognition requests to be active, as also stated in section 9.9 "If the
resource is in the recognizing state, the RECOGNIZE request MUST respond
with a failure status"

It is probably safer/simpler to assume hotword recognition will be done
by a separate recognition resource.  The mention of "both" should then
be removed from the spec.

Pierre

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

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 7 Jun 2005 07:14:40 -0700

This was not not imply parallel recognition. If I remember right this
wording was added specifically accomodate some recognition resources
that may not be capable of both normal and hot word recognition. Some
vendors might have implemented them as 2 separate resources. 
 
If you are refering to the statement to return failure when the
recognizer is in the RECOGNIZING state, this  was also why we have
created Cancel-If-Queue header to allow a RECOGNIZE command to cancel an
active RECOGNIZE command and go active. 
Anyway, this text describing queing/cancelling/stopping of requests is
being clarified based on Dave's request and I had sent a text proposal
to do that. That would streamline this and make it consistent. 
 
Sarvi

  _____  

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Burke
	Sent: Tuesday, June 07, 2005 5:41 AM
	To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail)
	Subject: Re: [Speechsc] MRCPv2 clarification

	... which is what my response was going to be until I read:
	  
	   "or implementations where a 
	   single recognition resource does not support both modes, they
can be 
	   implemented as separate resources and allocated to the same
SIP 
	   session with different MRCP session identifiers and share the
RTP 
	   audio feed. "
	 
	This loosely implies to me that the intent is for parallel
hotword and normal recognition. 
	 
	While MRCP should of course allow you to do this (forking media
to perform simultaneous recognitions), we should probably clarify , to
avoid confusion, that a single speechrecog is not intended to support
both modes concurrently.
	 
	- Dave

		----- Original Message ----- 
		From: Reifenrath, Klaus
<mailto:[email-masked]>  
		To: 'Pierre Forgues' <mailto:[email-masked]>  ; IETF
SPEECHSC (E-mail) <mailto:[email-masked]>  
		Sent: Tuesday, June 07, 2005 1:29 PM
		Subject: RE: [Speechsc] MRCPv2 clarification

		Hi Pierre,
		 
		"both" does not mean in parallel. But you can use the
same resource to do a "normal" recognition and later use the same
resource to perform a recognition in hotword mode.
		 
		Regards,
		Klaus

  _____  

		From: Pierre Forgues [mailto:[email-masked]] 
		Sent: Dienstag, 7. Juni 2005 14:12
		To: IETF SPEECHSC (E-mail)
		Subject: [Speechsc] MRCPv2 clarification

		Section 9 of the MRCPv2 specification includes the
following sentence:  "The recognition resource may support recognition
in the normal or hotword modes or both."  I'm not sure the same
recognition resource can support "both" because the state machinery does
not allow two concurrent recognition requests to be active, as also
stated in section 9.9 "If the resource is in the recognizing state, the
RECOGNIZE request MUST respond with a failure status"

		It is probably safer/simpler to assume hotword
recognition will be done by a separate recognition resource.  The
mention of "both" should then be removed from the spec.

		Pierre

  _____

---

From: "Pierre Forgues" <[email-masked]>
Date: Tue, 7 Jun 2005 10:26:01 -0400

That would suit me fine.  Thanks.  /Pierre

________________________________

From: Dave Burke [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2005 10:26 AM
To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF
SPEECHSC (E-mail)
Subject: Re: [Speechsc] MRCPv2 clarification

How about adding the clarification in parenthesis:

"The recognition resource may support recognition in the normal or
hotword modes or both (although note that a single speechrecog resource
does not perform normal and hotword mode recognitions in parallel)".

Dave

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

	From: Pierre Forgues <mailto:[email-masked]>  

	To: Shanmugham, Saravanan <mailto:[email-masked]>  ; Dave Burke
<mailto:[email-masked]>  ; Reifenrath, Klaus
<mailto:[email-masked]>  ; IETF SPEECHSC (E-mail)
<mailto:[email-masked]>  

	Sent: Tuesday, June 07, 2005 3:15 PM

	Anyway, the majority of vendors will be implementing hotword
using a separate resource because it does imply a concurrent recognition
on the same media stream.  I just think we need to clarify that when a
single recognition resource is used for hotword or normal mode, that
they cannot both be used concurrently.  The statement at the beginning
of section 9 is not clear in that respect.  

	Pierre

________________________________

	From: Shanmugham, Saravanan [mailto:[email-masked]] 
	Sent: Tuesday, June 07, 2005 10:15 AM
	To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC
(E-mail)
	Subject: RE: [Speechsc] MRCPv2 clarification

	This was not not imply parallel recognition. If I remember right
this wording was added specifically accomodate some recognition
resources that may not be capable of both normal and hot word
recognition. Some vendors might have implemented them as 2 separate
resources. 

	Anyway, this text describing queing/cancelling/stopping of
requests is being clarified based on Dave's request and I had sent a
text proposal to do that. That would streamline this and make it
consistent. 

	Sarvi

________________________________

		To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC
(E-mail)

		... which is what my response was going to be until I
read:

		   "or implementations where a 
		   single recognition resource does not support both
modes, they can be 
		   implemented as separate resources and allocated to
the same SIP 
		   session with different MRCP session identifiers and
share the RTP 
		   audio feed. "

		This loosely implies to me that the intent is for
parallel hotword and normal recognition. 

		While MRCP should of course allow you to do this
(forking media to perform simultaneous recognitions), we should probably
clarify , to avoid confusion, that a single speechrecog is not intended
to support both modes concurrently.

		- Dave

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

			From: Reifenrath, Klaus

			To: 'Pierre Forgues' <mailto:[email-masked]>
; IETF SPEECHSC (E-mail) <mailto:[email-masked]>  

			Hi Pierre,

			"both" does not mean in parallel. But you can
use the same resource to do a "normal" recognition and later use the
same resource to perform a recognition in hotword mode.

			Regards,

			Klaus

________________________________

			Section 9 of the MRCPv2 specification includes
the following sentence:  "The recognition resource may support
recognition in the normal or hotword modes or both."  I'm not sure the
same recognition resource can support "both" because the state machinery
does not allow two concurrent recognition requests to be active, as also
stated in section 9.9 "If the resource is in the recognizing state, the
RECOGNIZE request MUST respond with a failure status"

			Pierre

________________________________

________________________________

---

From: "Pierre Forgues" <[email-masked]>
Date: Tue, 7 Jun 2005 15:13:12 -0400

Couldn't have said it better myself.  Thanks!  /Pierre

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2005 2:35 PM
To: Shanmugham, Saravanan
Cc: Pierre Forgues; Dave Burke; Reifenrath, Klaus; IETF SPEECHSC
(E-mail)

Since I have the editing token at the moment, I decided to just deal  
with this now. I tweaked the text slightly to fit in better with the  
rest of the paragraph, so it now reads:

"The "speechrecog" can recognize regular speech as well as DTMF  
digits and hence SHOULD support grammars describing either speech or  
DTMF. The recognition resource may support recognition in the normal  
or hotword modes or both (although note that a single speechrecog  
resource does not perform normal and hotword mode recognitions  
simultaneously). For implementations where a single recognition  
resource does not support both modes, or simultaneous normal and  
hotword recognition is desired, the two modes can be invoked through  
separate resources and allocated to the same SIP dialog with  
different MRCP session identifiers and share the RTP audio feed."

On Jun 7, 2005, at 10:54 AM, Shanmugham, Saravanan wrote:

> thats sounds fine with me.
>
> Sarvi
>
> Sent: Tuesday, June 07, 2005 7:26 AM
> To: Dave Burke; Shanmugham, Saravanan; Reifenrath, Klaus; IETF  
> SPEECHSC (E-mail)
> hotword modes or both (although note   that a single speechrecog  
> resource does not perform normal and hotword mode recognitions in  
> parallel)".
>
>
>
> Dave
>
> From: Pierre Forgues
> To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF  
> SPEECHSC (E-mail)
>
> Anyway, the majority of vendors will be implementing hotword using  
> a separate resource because it does imply a concurrent recognition  
> on the same media stream.  I just think we need to clarify that  
> when a single recognition resource is used for hotword or normal  
> mode, that they cannot both be used concurrently.  The statement at  
> the beginning of section 9 is not clear in that respect.
>
>
>
> Pierre
>
>
>
> To: Dave Burke; Reifenrath, Klaus; Pierre Forgues; IETF SPEECHSC (E- 
> mail)
> created Cancel-If-Queue header to allow a RECOGNIZE command to  
> cancel an active RECOGNIZE command and go active.
>
> Anyway, this text describing queing/cancelling/stopping of requests  
> is being clarified based on Dave's request and I had sent a text  
> proposal to do that. That would streamline this and make it  
> consistent.
>
>
>
> Sarvi
>
>
>
> From: [email-masked] [mailto:[email-masked]]  
> On Behalf Of Dave Burke
>    implemented as separate resources and allocated to the same SIP
>    session with different MRCP session identifiers and share the RTP
>    audio feed. "
>
>
>
> This loosely implies to me that the intent is for parallel hotword  
> and normal recognition.
>
>
>
> While MRCP should of course allow you to do this (forking media to  
> perform simultaneous recognitions), we should probably clarify , to  
> avoid confusion, that a single speechrecog is not intended to  
> support both modes concurrently.
>
>
>
> - Dave
>
> To: 'Pierre Forgues' ; IETF SPEECHSC (E-mail)
>
> "both" does not mean in parallel. But you can use the same resource  
> to do a "normal" recognition and later use the same resource to  
> perform a recognition in hotword mode.
>
>
>
> Regards,
>
> Klaus
>
>
>
> Section 9 of the MRCPv2 specification includes the following  
> sentence:  "The recognition resource may support recognition in the  
> normal or hotword modes or both."  I'm not sure the same  
> recognition resource can support "both" because the state machinery  
> does not allow two concurrent recognition requests to be active, as  
> also stated in section 9.9 "If the resource is in the recognizing  
> state, the RECOGNIZE request MUST respond with a failure status"
>
>
> It is probably safer/simpler to assume hotword recognition will be  
> done by a separate recognition resource.  The mention of "both"  
> should then be removed from the spec.
>
>
>
> Pierre
>
>
>
>
>