Subject: RE: [Speechsc] MRCPv2 clarification

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

thats sounds fine with me.
 
Sarvi

  _____  

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

	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

		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

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

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

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 7 Jun 2005 14:34:59 -0400

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:

> To: Pierre Forgues; Shanmugham, Saravanan; Reifenrath, Klaus; IETF  
> SPEECHSC (E-mail)
> "The recognition resource may support recognition in the normal or  
> hotword modes or both (although note   that a single speechrecog  
> 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)
> 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  
> 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
> To: Reifenrath, Klaus; 'Pierre Forgues'; IETF SPEECHSC (E-mail)
> ... which is what my response was going to be until I read:
>
>
>
>    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
>
> 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
>
>
>
>
>

---

From: "Dave Burke" <[email-masked]>
Date: Tue, 7 Jun 2005 20:03:52 +0100

Better again - works for me.

----- Original Message ----- 
From: "David R. Oran" <[email-masked]>
To: "Shanmugham, Saravanan" <[email-masked]>
Cc: "IETF SPEECHSC (E-mail)" <[email-masked]>; "Pierre Forgues" 
<[email-masked]>; "Reifenrath, Klaus" <[email-masked]>; 
"Dave Burke" <[email-masked]>
Sent: Tuesday, June 07, 2005 7:34 PM
Subject: Re: [Speechsc] MRCPv2 clarification

> 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."
>
>> To: Dave Burke; Shanmugham, Saravanan; 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
>>
>>
>>
>> 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.
>>
>>
>>
>> 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
>>    single recognition resource does not support both modes, they  can be
>> This loosely implies to me that the intent is for parallel hotword  and 
>> normal recognition.
>>
>>
>>
>> avoid confusion, that a single speechrecog is not intended to  support 
>> both modes concurrently.
>>
>>
>>
>> - Dave
>>
>> "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: 
>> 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
>>
>>
>>
>>
>>