Subject: RE: [Speechsc] MRCPv2 clarification

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

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. 

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

________________________________

		_______________________________________________
		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: "Dave Burke" <[email-masked]>
Date: Tue, 7 Jun 2005 15:25:33 +0100

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 
  To: Shanmugham, Saravanan ; Dave Burke ; Reifenrath, Klaus ; IETF SPEECHSC (E-mail) 
  Sent: Tuesday, June 07, 2005 3:15 PM
  Subject: RE: [Speechsc] MRCPv2 clarification

  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. 

  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

       "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' ; IETF SPEECHSC (E-mail) 

      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" 

      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

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

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