Subject: Re: [speechsc] VoiceXML maxspeech timeout not implementable withMRCPv2

From: "Dave Burke" <[email-masked]>
Date: Mon, 7 Nov 2005 17:17:14 -0000

I agree with Andrew's analysis and that his proposed text clarification is 
warranted, i.e.

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

Dave

----- Original Message ----- 
From: "Andrew Wahbe" <[email-masked]>
To: "IETF SPEECHSC (E-mail)" <[email-masked]>
Sent: Friday, October 28, 2005 3:33 AM
Subject: Re: [speechsc] VoiceXML maxspeech timeout not implementable 
withMRCPv2

> 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:
>
>> 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:
>>
>>> 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
>>>
>>>
>

--------------------------------------------------------------------------------

> _______________________________________________
> 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: Mon, 7 Nov 2005 10:54:06 -0800

I understand and see his point. I think what he is proposing is what it
used to be before it was changed based on previous feed back. Hence I
want to be carefull before making this change. 

I have this as the only Open Issue in my slides for the SpeechSC
meeting. If there is concerns raised this is a simple enough change to
get into -09.

Sarvi 

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Dave Burke
     Sent: Monday, November 07, 2005 9:17 AM
     To: Andrew Wahbe; IETF SPEECHSC (E-mail)
     Subject: Re: [speechsc] VoiceXML maxspeech timeout not 
     implementable withMRCPv2
     
     I agree with Andrew's analysis and that his proposed text 
     clarification is warranted, i.e.
     
     "003 recognition-timeout: RECOGNIZE completed without a 
     match due to a recognition-timeout"
     
     Dave
     
     ----- Original Message -----
     From: "Andrew Wahbe" <[email-masked]>
     To: "IETF SPEECHSC (E-mail)" <[email-masked]>
     Sent: Friday, October 28, 2005 3:33 AM
     Subject: Re: [speechsc] VoiceXML maxspeech timeout not 
     implementable
     withMRCPv2

     >> I just noticed that my completion cause code analysis 
     was wrong in 
     >> one
     >> 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 
     >>> Actually, this is something I've raised before with 
     the 07 draft 
     >>> (see
     http://www1.ietf.org/mail-archive/web/speechsc/current/msg0
     1510.html
     >>> )
     >>> 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.
     >>>
     >>> So we are left with recognition timeout. It could be a 
     complete 
     >>> match
     >>> 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/msg0
     1501.html
     >>> proposal (well now it just a Nuance proposal) from a 
     year and a half
     http://www1.ietf.org/mail-archive/web/speechsc/current/msg0
     0560.html
     >>> Andrew

     -----------------------------------------------------------
     ---------------------