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

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 23 Aug 2005 23:43:38 -0700

The idea of being able to send it opn the RECOGNIZE is to reduce the
time and not increase it. 

By default, the value is 0. When you do a SET-PARAMS and set it to say
10000 it sets the buffering at the server to 10 seconds.

This does not mean that every RECOGNIZE should use this entire 10s of
buffer. On an individual RECOGNIZE method basis the client should be
able to use 0 - 10s of that buffer. This would be the last X seconds of
the buffer before the RECOGNIZE method is recieved the rest would be
discarded.

Achieves more flexibility than plain flushing true or false.

Sarvi

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Eric Burger
     Sent: Tuesday, August 23, 2005 11:14 PM
     To: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     [not as chair]
     
     I can see something like "Type-Ahead" for SET/GET-PARAMS, 
     which sets a global digit buffer.  I would suggest a more 
     descriptive name, like DTMF-Buffer-Time.
     
     That said, I don't see it working for the RECOGNIZE 
     method.  The speech resource needs to know *before* the 
     RECOGNIZE request that it needs to buffer DTMF.  If it 
     comes in with the RECOGNIZE request, it will be too late.
     
     For example:
     
     SET-PARAMS
     DTMF-Buffer-Time: 10000
     ...
     <sets global buffer to 10s; platform keeps 10 seconds of 
     DTMF buffered>

     RECOGNIZE
     DTMF-Buffer-Time: 20000
     ...
     <sets buffer to 20s.  Oops: platform already dropped first 
     10 seconds because it was only buffering 10 seconds>

     The sensible per-RECOGNIZE attribute is to flush the 
     buffer.  While one might be tempted to say 
     "DTMF-Buffer-Time: 0" means flush the buffer, I am sure 
     someone will try to use it with a non-zero value.  I would 
     offer we use a different attribute to indicate flushing 
     the buffer before recognition, like "Flush-DTMF: true".
     
     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Corby Anderson
     Sent: Tuesday, August 23, 2005 7:34 PM
     To: [email-masked]
     Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead
     
     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
     >
     >     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
     >  
     >
     
     _______________________________________________
     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: "Dave Burke" <[email-masked]>
Date: Wed, 24 Aug 2005 10:52:20 +0100

Sounds like a lot of dials to play with: What is the use-case warranting the 
extra complexity for overriding the SET-PARAMed buffer length on a per 
RECOGNIZE?

The two capabilities that you want (IMO) are:
    1. Configuration: How long is the buffer?
    2. Action: Flush buffer

For configuration, I'd rather see a SET-PARAMs but with a non-zero default - 
say 10 seconds (2 x default inter-digit time).  For flushing, I'd rather see 
a boolean header on RECOGNIZE for simplicity. That way, out-of-the-box, easy 
things are easy and harder things are still possible...

I don't like the term flush. Is one flushing the DTMF into the recognizer or 
out into the ether(net)? Hence why I suggested Clear-DTMF-Buffer.

Dave

----- Original Message ----- 
From: "Shanmugham, Saravanan" <[email-masked]>
To: "Eric Burger" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 24, 2005 7:43 AM
Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead

Sarvi

     -----Original Message-----
     From: [email-masked]
     [mailto:[email-masked]] On Behalf Of Eric Burger
     Sent: Tuesday, August 23, 2005 11:14 PM
     To: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead

     [not as chair]

     For example:

     SET-PARAMS
     DTMF-Buffer-Time: 10000
     ...

     RECOGNIZE
     DTMF-Buffer-Time: 20000
     ...

     -----Original Message-----
     From: [email-masked]
     [mailto:[email-masked]] On Behalf Of Corby Anderson
     Sent: Tuesday, August 23, 2005 7:34 PM
     To: [email-masked]
     Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead

     Corby Anderson
     Tellme Networks, Inc.

     type-ahead and
     (generally)
     see if there
     set to some
     the recognize as
     field as well,
     more flexible.
     the RECOGNIZE
     is reached.
     any active DTMF
     significant amount of
     application
     time any DTMF
     type-ahead is common
     that type
     4.1.8). Can
     DTMF)? If so,
     -------------
     -