Subject: [speechsc] VoiceXML maxspeech timeout not implementable with MRCPv2

From: Andrew Wahbe <[email-masked]>
Date: Thu, 27 Oct 2005 22:45:23 -0400

Actually, this is something I've raised before with the 07 draft (see 
http://www1.ietf.org/mail-archive/web/speechsc/current/msg01510.html) 
but is still not fixed in 08.

I don't see a way to implement the VoiceXML maxspeech timeout with the 
current recognition completion cause codes. The semantics of the 
Recognition Timer match those of VoiceXML maxspeech timeout. There are 
currently 2 cause codes related to this timer:

003 recognition-timeout: RECOGNIZE in hotword mode completed without a 
match due to a recognition-timeout

008 success-maxtime: RECOGNIZE request terminated because speech was too 
long but whatever was spoken till that point was a full match.

But what should be thrown in a non-hotword recognition when the timer 
fires and there is no match? It can't be 001 no-match; the VoiceXML 
interpreter will not be able to distinguish a "nomatch" from "maxspeech" 
in this case.

Let's take a step back. If we really want to describe what happened, 
then I think we need to communicate to the client 1) why the recognition 
was stopped and 2) if the result a no-match, a partial match, or a 
complete match when it stopped.

1) The recognition can stop for the following reasons (the related cause 
codes in parens):

no-input timeout (002)
complete timeout (000)
incomplete timeout (001 013)
recognition timeout (003 and 008)
speech too early (007)
cancelled (011)
various errors (004, 005, 006, 009, 010, 012)

2) The result is irrelevant for no-input, speech too early, cancelled, 
and the errors. This leaves complete timeout, incomplete timeout, and 
recognition timeout. By the definition of complete timeout, this is 
always a complete match (000). Also by definition, incomplete timeout 
could result in a no match (001) or a partial match (013) -- though 
VoiceXML will likely throw nomatch for either.

So we are left with recognition timeout. It could be a complete match 
(008 by the definition in section 9.4.11) or a partial match (008 by the 
definition in section 9.4.7), or a no-match...  well if it was a hotword 
recognition we have 003; for the normal case, we have nothing.

So hopefully I have clarified my earlier point that Recognition Complete 
Cause codes 003 and 008 need revisiting. Sorry to be so long winded but 
I think it's important that VoiceXML be implementable using MRCPv2; it 
is a very common use case for the specification.

Before proposing a solution, I would like to again ask why we need to 
have a special cause code for recognition-timeout in the hotword case. 
The answer to this question is here:
http://www1.ietf.org/mail-archive/web/speechsc/current/msg01501.html

But I still don't see why you need a special completion cause to say 
that the timer expired in hotword mode. The client knows what mode the 
recognition is in. You just need to tell it that the timer fired.

What the client does need to know is if there is a valid result for it 
to process. Thus I propose that 003 be rewritten as follows:

003 recognition-timeout: RECOGNIZE in hotword mode completed without a 
match due to a recognition-timeout

This will bring it back in line with the earlier Scansoft & Nuance 
proposal (well now it just a Nuance proposal) from a year and a half ago:
http://www1.ietf.org/mail-archive/web/speechsc/current/msg00560.html

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

---

From: Andrew Wahbe <[email-masked]>
Date: Thu, 27 Oct 2005 23:29:04 -0400

I just noticed that my completion cause code analysis was wrong in one case:

- between drafts 06 and 07 it seems the definition of Speech Incomplete 
Timeout (Section 9.4.16) was changed so that "partial-match" (013) was 
returned when it fired instead of "no-match" (001).

So I guess what we are saying is that another way of terminating 
recognition is that the speech is just not matching the grammar at all 
and that is what yeilds no-match (001). (Though I could have sworn that 
a recognizer waits until you were done talking even if the utterance 
wasn't matching at all and that incomplete timeout was used in that 
case. Anyone care to clarify?)

Anyways, I don't think this changes my real point below.

Andrew

Andrew Wahbe wrote:

> 008 success-maxtime: RECOGNIZE request terminated because speech was 
> too long but whatever was spoken till that point was a full match.
>
> interpreter will not be able to distinguish a "nomatch" from 
> "maxspeech" in this case.
>
> then I think we need to communicate to the client 1) why the 
> recognition was stopped and 2) if the result a no-match, a partial 
> match, or a complete match when it stopped.
>
> 1) The recognition can stop for the following reasons (the related 
> cause codes in parens):
>
> no-input timeout (002)
> complete timeout (000)
> (008 by the definition in section 9.4.11) or a partial match (008 by 
> the definition in section 9.4.7), or a no-match...  well if it was a 
> hotword recognition we have 003; for the normal case, we have nothing.
>
> So hopefully I have clarified my earlier point that Recognition 
> Complete Cause codes 003 and 008 need revisiting. Sorry to be so long 
> winded but I think it's important that VoiceXML be implementable using 
> MRCPv2; it is a very common use case for the specification.
>

---

From: Andrew Wahbe <[email-masked]>
Date: Thu, 27 Oct 2005 23:33:20 -0400

Man I should stop writing emails so late at night:
My new proposed text for 003 wasn't changed at all. This is what I am 
proposing:

003 recognition-timeout: RECOGNIZE completed without a match due to a 
recognition-timeout

Andrew

Andrew Wahbe wrote:

> - between drafts 06 and 07 it seems the definition of Speech 
> Incomplete Timeout (Section 9.4.16) was changed so that 
> "partial-match" (013) was returned when it fired instead of "no-match" 
> (001).
>
> and that is what yeilds no-match (001). (Though I could have sworn 
> that a recognizer waits until you were done talking even if the 
> utterance wasn't matching at all and that incomplete timeout was used 
> in that case. Anyone care to clarify?)
>
>> I don't see a way to implement the VoiceXML maxspeech timeout with 
>> the current recognition completion cause codes. The semantics of the 
>> Recognition Timer match those of VoiceXML maxspeech timeout. There 
>> are currently 2 cause codes related to this timer:
>>
>> 003 recognition-timeout: RECOGNIZE in hotword mode completed without 
>> a match due to a recognition-timeout
>>
>> 2) The result is irrelevant for no-input, speech too early, 
>> cancelled, and the errors. This leaves complete timeout, incomplete 
>> timeout, and recognition timeout. By the definition of complete 
>> timeout, this is always a complete match (000). Also by definition, 
>> incomplete timeout could result in a no match (001) or a partial 
>> match (013) -- though VoiceXML will likely throw nomatch for either.
>>
>> winded but I think it's important that VoiceXML be implementable 
>> using MRCPv2; it is a very common use case for the specification.
>>
>> have a special cause code for recognition-timeout in the hotword 
>> case. The answer to this question is here:
>> that the timer expired in hotword mode. The client knows what mode 
>> the recognition is in. You just need to tell it that the timer fired.
>>
>> What the client does need to know is if there is a valid result for 
>> it to process. Thus I propose that 003 be rewritten as follows:
>>
>> 003 recognition-timeout: RECOGNIZE in hotword mode completed without 
>> a match due to a recognition-timeout
>>