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

From: "Pierre Forgues" <[email-masked]>
Date: Tue, 23 Aug 2005 16:35:56 -0400

We agree with this position.  

We have implemented dtmf type ahead in our product and adding a header
to give the application the choice to clear the buffer on the next
RECOGNIZE but by default operating on the dtmf buffer is the right
decision.  /Pierre

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Burke
Sent: Tuesday, August 23, 2005 3:29 PM
To: Klaus Reifenrath; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Speechsc] Problem with DTMF type-ahead 

Nice catch. This is a must fix in my opinion.

Here's my thought on a resolution:

By default, the recognizer (dtmfrecog or speechrecog) should buffer
DTMF. This means that if some DTMF digits are entered outside of the
Recognizing State and a RECOGNIZE request made later, the buffered
digits and their timings are applied to that recognition. To clear the
buffer, a header can be added to RECOGNIZE called Clear-DTMF-Buffer:
true. Any DTMF digits buffered up to that point are discarded. 

Can supply the text changes if that's helpful (also note small
refactoring needed in last sentence of section 9.9 regarding not
buffering anything before RECOGNIZE). 

Dave

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

	From: Reifenrath, Klaus <mailto:[email-masked]>  

	To: [email-masked]' ; [email-masked]' 

	Cc: [email-masked]' 

	Sent: Tuesday, August 23, 2005 4:41 PM

	Subject: [Speechsc] 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

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 23 Aug 2005 13:59:00 -0700

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 

	Thanks,
	Klaus

---

From: "Jeff Haynie" <[email-masked]>
Date: Tue, 23 Aug 2005 18:19:44 -0400

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 

 

Sarvi

	Thanks,
	Klaus

---

From: "Jeff Haynie" <[email-masked]>
Date: Tue, 23 Aug 2005 20:04:24 -0400

Sarvi, et al:
 
Is there a use case for speak ahead?  I can't honestly think of one ...
maybe Dan or someone else knows of one they could speak too.  It also
seems like that would introduce a lot of other complexity with partial
packets, etc. that you isn't the case with DTMF.
 
Jeff

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

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.  

	 
	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

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 24 Aug 2005 02:14:19 -0400

[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
>
------------------------------------------------------------------------
>     *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
>         *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
>
>-----------------------------------------------------------------------
-

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 24 Aug 2005 07:31:13 -0400

[not as chair]
We went through this whole discussion for KPML.  No one ever had a use
case for "keep the last x seconds".  In fact, one either buffered digits
or flushed them.

If you have an 8,000 port media engine, with one hour call times, and
continuous digit entry without the digits ever getting off the queue,
and the digit entry is computer generated (i.e., as fast as possible),
you need:
   (8,000 ports) * (3,600,000ms/port) / (60ms / digit) = 480MB

I would offer that if you have an 8,000 port media processing device,
less than half a gigabyte for digit buffering is nothing.

In English, that means that you can realistically have infinite digit
buffering.

That makes the protocol MUCH easier, interoperation MUCH easier, and
implementation MUCH easier.

[really not as chair]
As for the term, I didn't think anyone had an alternative interpretation
of the term "flush".  However, I suppose "clear" is OK.

-----Original Message-----
From: Dave Burke [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 5:52 AM
To: Shanmugham, Saravanan; Eric Burger; [email-masked]
Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead

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

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

     Corby Anderson
     Tellme Networks, Inc.

     > is not speak ahead as well?
     -----------------------------------------------------------
     -------------
     >     DTMF-Buffer: <true|false>
     -----------------------------------------------------------
     -------------
     >     but the <time-in-milliseconds> approach is little
     more flexible.
     -----------------------------------------------------------
     -------------
     -

---

From: "Pierre Forgues" <[email-masked]>
Date: Wed, 24 Aug 2005 14:01:01 -0400

Let's limit the capability to DTMF type-ahead.  I've heard of power
users, but I don't think it is feasible or desirable to talk about
people speaking before the beginning of prompts.  This would add
unnecessary complexity in my opinion.

I like the terminology of "clearing" a buffer rather than flushing.

Pierre

To: Jeff Haynie; Klaus Reifenrath; [email-masked]

Sarvi

	instead.

	Jeff

	Sarvi

		From: Reifenrath, Klaus

		Thanks,
		Klaus

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 24 Aug 2005 11:22:10 -0700

Ok.
Lets limit this buffer to digits and not speech. 
Lets also stick to clear buffer operation in RECOGNIZE method.

But should be the buffer size. Settable by the client? Platform specific
fixed? Settable client on a per RECOGNIZE basis.

Unlimited size may be ok for implementation, but is it practical and
what does it mean in actual usage. 
If the recognizer channel was allocated at the beginning of the call,
and at some later point in the call, much later, we do a recognize. Does
this mean that any digits pressed since the beginning of the call when
the resource was allocated or the previous RECOGNIZE, are used as part
of the type-ahead?

Sarvi 

     -----Original Message-----
     From: Eric Burger [mailto:[email-masked]] 
     Sent: Wednesday, August 24, 2005 4:31 AM
     To: Dave Burke; Shanmugham, Saravanan
     Cc: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     [not as chair]
     We went through this whole discussion for KPML.  No one 
     ever had a use case for "keep the last x seconds".  In 
     fact, one either buffered digits or flushed them.
     
     If you have an 8,000 port media engine, with one hour call 
     times, and continuous digit entry without the digits ever 
     getting off the queue, and the digit entry is computer 
     generated (i.e., as fast as possible), you need:
        (8,000 ports) * (3,600,000ms/port) / (60ms / digit) = 480MB
     
     I would offer that if you have an 8,000 port media 
     processing device, less than half a gigabyte for digit 
     buffering is nothing.
     
     In English, that means that you can realistically have 
     infinite digit buffering.
     
     That makes the protocol MUCH easier, interoperation MUCH 
     easier, and implementation MUCH easier.
     
     [really not as chair]
     As for the term, I didn't think anyone had an alternative 
     interpretation of the term "flush".  However, I suppose 
     "clear" is OK.
     
     -----Original Message-----
     From: Dave Burke [mailto:[email-masked]]
     Sent: Wednesday, August 24, 2005 5:52 AM
     To: Shanmugham, Saravanan; Eric Burger; [email-masked]
     Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead
     
     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?

     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

     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.

     Sarvi
     
          -----Original Message-----
     
          [not as chair]

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

          RECOGNIZE
          DTMF-Buffer-Time: 20000
          ...

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

     
          Corby Anderson
          Tellme Networks, Inc.

          -

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 24 Aug 2005 14:39:29 -0400

[not as chair]
I still see no use case for NOT having the buffer go back to the
beginning of time.  Since there is no need for a limit to the buffer
size, why complicate things?

Because someone will always come up with a bizarre corner case, KPML
does do a circular buffer thing, dropping real old tones, and indicating
that old tones were lost.  However, even on a memory constrained
telephone, that would be hours of digits being entered continuously
(i.e., still probably never could happen).

Thus, to the question of "Should the client set the buffer size?" the
answer is "no".  The size is effectively infinite.  "Is the size set by
the platform?"  I would say "no", because there is no reason to.
However, if you are ultra paranoid about a DoS attack that runs for a
really long time (which in itself is going to be the source of the
problem, not that your DTMF buffer overflows), I suppose one could say
"yes".

My personal opinion is still to just have an infinite buffer size, going
back to the last recognition / start of buffering / last flush.

-----Original Message-----
From: Shanmugham, Saravanan [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 2:22 PM
To: Eric Burger; Dave Burke
Cc: [email-masked]
Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead

Ok.

Sarvi 

     -----Original Message-----
     From: Eric Burger [mailto:[email-masked]] 
     Sent: Wednesday, August 24, 2005 4:31 AM
     To: Dave Burke; Shanmugham, Saravanan
     Cc: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     [not as chair]

     

     [really not as chair]
     
     -----Original Message-----
     From: Dave Burke [mailto:[email-masked]]
     Sent: Wednesday, August 24, 2005 5:52 AM
     To: Shanmugham, Saravanan; Eric Burger; [email-masked]
     Subject: Re: [Speechsc] RE: Problem with DTMF type-ahead

     

     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-----
     
          [not as chair]

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

          RECOGNIZE
          DTMF-Buffer-Time: 20000
          ...

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

     
          Corby Anderson
          Tellme Networks, Inc.

          -

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 24 Aug 2005 12:56:46 -0700

I am less concerned about DoS attacks. 
We are implementing a recognition resource that could potentially be
attached a 
Speaker for the entire period of the call, without actually doing any
actual 
Recognition. Soemtime way into the call the application might play a
prompt and start a Recognize. The question is will any digits pressed
during the call be applied because the buffer was too long. Note that we
are actually saying the resource would be buffering digits even when
there is no Recognize happenning.

Anyway, If there is much interest in the group for supporting variable
buffer size, Iwill not push it.

Sarvi

     -----Original Message-----
     From: Eric Burger [mailto:[email-masked]] 
     Sent: Wednesday, August 24, 2005 11:39 AM
     To: Shanmugham, Saravanan
     Cc: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     [not as chair]
     I still see no use case for NOT having the buffer go back 
     to the beginning of time.  Since there is no need for a 
     limit to the buffer size, why complicate things?
     
     Because someone will always come up with a bizarre corner 
     case, KPML does do a circular buffer thing, dropping real 
     old tones, and indicating that old tones were lost.  
     However, even on a memory constrained telephone, that 
     would be hours of digits being entered continuously (i.e., 
     still probably never could happen).
     
     Thus, to the question of "Should the client set the buffer 
     size?" the answer is "no".  The size is effectively 
     infinite.  "Is the size set by the platform?"  I would say 
     "no", because there is no reason to.
     However, if you are ultra paranoid about a DoS attack that 
     runs for a really long time (which in itself is going to 
     be the source of the problem, not that your DTMF buffer 
     overflows), I suppose one could say "yes".
     
     My personal opinion is still to just have an infinite 
     buffer size, going back to the last recognition / start of 
     buffering / last flush.
     
     -----Original Message-----
     From: Shanmugham, Saravanan [mailto:[email-masked]]
     Sent: Wednesday, August 24, 2005 2:22 PM
     To: Eric Burger; Dave Burke
     Cc: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     Ok.
     
     But should be the buffer size. Settable by the client? 
     Platform specific fixed? Settable client on a per RECOGNIZE basis.
     
     Unlimited size may be ok for implementation, but is it 
     practical and what does it mean in actual usage. 
     If the recognizer channel was allocated at the beginning 
     of the call, and at some later point in the call, much 
     later, we do a recognize. Does this mean that any digits 
     pressed since the beginning of the call when the resource 
     was allocated or the previous RECOGNIZE, are used as part 
     of the type-ahead?
     
     Sarvi 
     
          -----Original Message-----
          
          [not as chair]

          

          [really not as chair]
          
          -----Original Message-----

          

          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
               ...
               <sets buffer to 20s.  Oops: platform already 
     dropped first
               10 seconds because it was only buffering 10 seconds>

               someone will try to use it with a non-zero 
     value.  I would
          
               -----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.

               

               >         should be handled: DTMF input is 
     collected after
               the RECOGNIZE
               >         request is received until a term-char 
     or timeout
               is reached.
               >         time between when one result is 
     processed by the
               application
               >         for frequent users of IVR systems, and 
     buffering
               that type
               
               -

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 24 Aug 2005 16:01:27 -0400

Having variable or infinite buffering would not change the client
behavior in the example given below.

At some point, the client says, "I am interested in digits starting
NOW."  The "NOW" point is where the client flushes the buffer.  Anything
else would not be deterministic.

-----Original Message-----
From: Shanmugham, Saravanan [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 3:57 PM
To: Eric Burger
Cc: [email-masked]
Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead

Sarvi

     -----Original Message-----
     From: Eric Burger [mailto:[email-masked]] 
     Sent: Wednesday, August 24, 2005 11:39 AM
     To: Shanmugham, Saravanan
     Cc: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     [not as chair]

     
     
     -----Original Message-----
     From: Shanmugham, Saravanan [mailto:[email-masked]]
     Sent: Wednesday, August 24, 2005 2:22 PM
     To: Eric Burger; Dave Burke
     Cc: [email-masked]
     Subject: RE: [Speechsc] RE: Problem with DTMF type-ahead
     
     Ok.

     
     Sarvi 
     
          -----Original Message-----
          
          [not as chair]

          

          [really not as chair]
          
          -----Original Message-----

          

          Dave
          
          ----- Original Message -----

          

          Sarvi
          
               -----Original Message-----
          
               [not as chair]

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

               RECOGNIZE
               DTMF-Buffer-Time: 20000
               ...

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

          
               Corby Anderson
               Tellme Networks, Inc.

               

     collected after
               the RECOGNIZE
     or timeout
               is reached.
     processed by the
               application
     buffering
               that type
               
               -