Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 23 Aug 2005 15:30:39 -0700

Are we assuming then that this is only limited to DTMF type-ahead and is
not speak ahead as well?
 
Sarvi

________________________________

	From: Jeff Haynie [mailto:[email-masked]] 
	Sent: Tuesday, August 23, 2005 3:20 PM
	To: Shanmugham, Saravanan; Reifenrath, Klaus;
[email-masked]
	Cc: [email-masked]
	Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead 

	It would seem like we're not trying to buffer audio (generally)
but only the DIGIT values themselves.  

	It would seem better to just be a header such as:
	 
	DTMF-Buffer: <true|false>
	 
	instead.
	 
	Jeff

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Shanmugham, Saravanan
	Sent: Tuesday, August 23, 2005 4:59 PM
	To: Reifenrath, Klaus; [email-masked]
	Cc: [email-masked]
	Subject: [Speechsc] RE: Problem with DTMF type-ahead 

	I had typed this response out earlier but wanted to see if there
was any support for this capability. So sending it out now.
	 
	The solution I would suggest is a new header 
	           Type-Ahead: <time-in-milli-seconds> 
	header that can be sent on the SET-PARAMS, GET-PARAMS and
RECOGNIZE methods.
	 
	default is 0 which is todays no buffering case. If set to some
value, the resource is expected to buffer upto <time-in-milliseconds> of
audio and use it during the recognize as a type-ahead buffer. I can see
this being a boolean field as well, but the <time-in-milliseconds>
approach is little more flexible.
	 
	Sarvi

________________________________

		From: Reifenrath, Klaus
[mailto:[email-masked]] 
		Sent: Tuesday, August 23, 2005 8:41 AM
		To: Shanmugham, Saravanan; [email-masked]'
		Cc: [email-masked]'
		Subject: Problem with DTMF type-ahead 

		The MRCP and MRCPv2 specifications define how DTMF input
should be handled: DTMF input is collected after the RECOGNIZE request
is received until a term-char or timeout is reached. Then a result or
no-match is returned based on any active DTMF grammars. The problem is
there can be a significant amount of time between when one result is
processed by the application and the next grammar is activated. During
that time any DTMF input received will be lost. Such DTMF type-ahead is
common for frequent users of IVR systems, and buffering that type ahead
is required by VoiceXML 2.0 (see section 4.1.8). Can this requirement of
VoiceXML be implemented using MRCP (assuming that the media source
CANNOT buffer DTMF)? If so, how is it done? 

		Thanks,
		Klaus 

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

---

From: Corby Anderson <[email-masked]>
Date: Tue, 23 Aug 2005 16:33:40 -0700

I prefer the flexible "Type-Ahead: <time-in-milliseconds>" approach.  
This would be useful for implementing vxml listen states that happen 
after data tags.  If a data fetch takes longer than several seconds, you 
might not want to play dtmf that is older than some limit.

Corby Anderson
Tellme Networks, Inc.

Shanmugham, Saravanan wrote:

> Are we assuming then that this is only limited to DTMF type-ahead and 
> is not speak ahead as well?
>  
> Sarvi
>
>     ------------------------------------------------------------------------
>     *From:* Jeff Haynie [mailto:[email-masked]]
>     *Sent:* Tuesday, August 23, 2005 3:20 PM
>     *To:* Shanmugham, Saravanan; Reifenrath, Klaus;
>     [email-masked]
>     *Cc:* [email-masked]
>     *Subject:* RE: [Speechsc] RE: Problem with DTMF type-ahead
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Shanmugham,
>     Saravanan
>     *Sent:* Tuesday, August 23, 2005 4:59 PM
>     *To:* Reifenrath, Klaus; [email-masked]
>     *Cc:* [email-masked]
>     *Subject:* [Speechsc] RE: Problem with DTMF type-ahead
>
>      
>     value, the resource is expected to buffer upto
>     <time-in-milliseconds> of audio and use it during the recognize as
>     a type-ahead buffer. I can see this being a boolean field as well,
>     but the <time-in-milliseconds> approach is little more flexible.
>      
>     Sarvi
>
>         ------------------------------------------------------------------------
>         *From:* Reifenrath, Klaus [mailto:[email-masked]]
>         *Sent:* Tuesday, August 23, 2005 8:41 AM
>         *To:* Shanmugham, Saravanan; [email-masked]'
>         *Cc:* [email-masked]'
>         *Subject:* Problem with DTMF type-ahead
>
>         should be handled: DTMF input is collected after the RECOGNIZE
>         request is received until a term-char or timeout is reached.
>         Then a result or no-match is returned based on any active DTMF
>         grammars. The problem is there can be a significant amount of
>         time between when one result is processed by the application
>         and the next grammar is activated. During that time any DTMF
>         input received will be lost. Such DTMF type-ahead is common
>         for frequent users of IVR systems, and buffering that type
>         ahead is required by VoiceXML 2.0 (see section 4.1.8). Can
>         this requirement of VoiceXML be implemented using MRCP
>         (assuming that the media source CANNOT buffer DTMF)? If so,
>         how is it done?
>
>         Thanks,
>         Klaus
>
>------------------------------------------------------------------------
>