Subject: RE: [Speechsc] START-OF-SPEECH in DTMF-only mode

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Tue, 5 Jul 2005 09:22:12 -0700

I agree with Dave's analysis. The purpose of this event was barge-in. 
And barge-in should happen for both DTMF and speech.

Is there a case where you think it should not behave this way. If soe,
please provide a scenario where you think
    1. Barge-in should happen for DTMF and not voice or vice-versa.
    2. You would benefit from the client knowing what caused the
barge-in, DTMF Vs speech.

Sarvi

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of David R Oran
     Sent: Tuesday, July 05, 2005 5:24 AM
     To: Klaus Reifenrath
     Cc: [email-masked]'
     Subject: Re: [Speechsc] START-OF-SPEECH in DTMF-only mode

     On Jul 5, 2005, at 3:46 AM, Reifenrath, Klaus wrote:
     
     > The current spec is not clear when START-OF-SPEECH need 
     to be send in 
     > the following scenarios:
     > A) The client requested a DTMF Recognizer. Is the 
     START-OF-SPEECH 
     > event send to the client also if speech was detected?
     I suspect so, since one of the prime purposes is to enable 
     client- mediated barge-in handling. However, if the 
     recognizer is in fact only capable of recognizing DTMF 
     then it may in fact not report anythin unless it's using 
     some primitive thresholding machinery, like a SN threshold.
     > B) The client requested a Speech Recognizer, but only 
     activated DTMF 
     > grammars. Is the START-OF-SPEECH event send to the 
     client also if 
     > speech was detected?
     Again, I'd say yes, for the same reason as above.
     > I think in both cases START-OF-SPEECH should only be send after 
     > detecting a DTMF digit (see Figure 12 of VoiceXML 2.0: http:// 
     > www.w3.org/TR/voicexml20/#dmlATiming).
     We seem to have reached different conclusions. I'd be 
     interested in why you think my analysis above is wrong.
     
     Dave.
     
     > 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

---

From: "Dave Burke" <[email-masked]>
Date: Tue, 5 Jul 2005 17:54:15 +0100

Inline.

Dave

----- Original Message ----- 
From: "Shanmugham, Saravanan" <[email-masked]>
To: "David R Oran" <[email-masked]>; "Klaus Reifenrath" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 05, 2005 5:22 PM
Subject: RE: [Speechsc] START-OF-SPEECH in DTMF-only mode

DB> You want to do a DTMF recognition only because it is noisy. While 
waiting for DTMF input, the speechrecog resource (or advanced dtmfrecog) 
generates a START-OF-SPEECH because it heard some speech. The client does 
not want to stop prompt playing unless DTMF was heard but it can't tell by 
the START-OF-SPEECH whether speech or DTMF was heard. Similarly vice versa.

DB> See previous comment. And previous e-mail: either add an inputmodes 
header (taking value speech, dtmf, both) to the RECOGNIZE request or add a 
header to the START-OF-SPEECH event indicating DTMF or speech.

Sarvi

     -----Original Message-----
     From: [email-masked]
     [mailto:[email-masked]] On Behalf Of David R Oran
     Sent: Tuesday, July 05, 2005 5:24 AM
     To: Klaus Reifenrath
     Cc: [email-masked]'
     Subject: Re: [Speechsc] START-OF-SPEECH in DTMF-only mode

     to be send in
     START-OF-SPEECH
     activated DTMF
     client also if

     Dave.

---

From: David R Oran <[email-masked]>
Date: Tue, 5 Jul 2005 14:08:22 -0400

On Jul 5, 2005, at 12:54 PM, Dave Burke wrote:

> Inline.
>
> Dave
>
> ----- Original Message ----- From: "Shanmugham, Saravanan"  
> <[email-masked]>
> DB> You want to do a DTMF recognition only because it is noisy.  
> While waiting for DTMF input, the speechrecog resource (or advanced  
> dtmfrecog) generates a START-OF-SPEECH because it heard some  
> speech. The client does not want to stop prompt playing unless DTMF  
> was heard but it can't tell by the START-OF-SPEECH whether speech  
> or DTMF was heard. Similarly vice versa.
>
It's an interesting design question what part of the policy resides  
at the client and what at the server, and who makes the "final  
decision" about whether what was heard was relevant to the control  
channel. Right now we (IMO) have a weird partitioning in many cases  
where the client basically says "do what I mean", but there are no  
constraints of what the server actually does, and no normalized basis  
for the client to figure out what to set various magic numbers to  
(e.g. sensitivity).

In this case the only thing the client needs to decide is whether to  
kill the prompt because the server thinks something that would  
interfere with the feedback ear/mouth/finger control happened. What  
this says to me is that it isn't necessarily a good idea for the  
client to have more knobs to control the server (especially if those  
knows are just more value/policy input ungrounded in any physics/ 
acoustics). On the other hand, having the server tell the client more  
about what it thinks is going on is probably valuable.

So, Coming to the point after this long rambling introduction, I  
think it would in fact be useful for the START-Of-SPEECH event to  
indicate some extra information, for example:
a) I got something enough above the noise floor to qualify for  
exceeding the "Sensisitvity" parameter you sent in on the request but  
I really can't tell what it is (could be a hippopatmus fart, or a  
siren in the background, or captain crunch trying to whistle DTMF).
b) I think I'm hearing speech
c) I think I'm hearing DTMF

> DB> See previous comment. And previous e-mail: either add an  
> inputmodes header (taking value speech, dtmf, both) to the  
> RECOGNIZE request or add a header to the START-OF-SPEECH event  
> indicating DTMF or speech.
>
I'm leaning in your direction on this latter point - as should be  
evident from what I wrote above.