Subject: RE: [speechsc] VoiceXML maxspeech timeout not implementable withMRCPv2 - RESEND

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Thu, 10 Nov 2005 13:38:34 -0800

I just re-read this whole description and came to a different
conlcusion.

When a recongizer is started and enough speech has been collected to be
able to process.

The match conditions for the spoken speech and grammar matching upto
that point can be one of the following
   no-match
   partial-match
   complete-match
You could go one step further and say a complete-match can be of 2
sub-classes on further grammar possibilities(Is there value to doing
this. My thinking is not, Any thoughts)
   complete-match-with-more-possibilities
   Complete-match-with-no-more-possibilities

Theoretically speaking, no-match could be decided the moment that the
speaker speaks something that does not match anything, which could be
even the first word.
But, if I understand right, most commercial recognizers today don't
match the speech as they are spoken, but rather wait for
end-pointing/some-silience or a timer before doing the matching.

NOW, walking through what happens during a non-hotword RECOGNIZE
operation.

The Recognition-Timer is started right at the beginning of the RECOGNIZE
operation.

When silence/enpoint happens they take the speech collected upto that
point, and match it with the grammar and do the following.
   1. If there was NO match - they generate   "no-match 001" completion
cause code.
   2. If there was partial-match - They start the
Speech-Incomplete-Timer
   3. If there was complete-match(both sub types) - They start the
Speech-Complete-Timer.

Now lets look at the cases of the different timers expiring.

Speech-Incomplete-Timer expires, we return partial-match 013 
When Speech-Complete-Timer expires, we return "success" 000.
When Recognition-Timer expires we have multiple possibilities based on
the grammar match condition.
    1. no-match 001
    2. partial-match 013
    3. succcess (which is differentiated as success-maxtime 008)

So I don't see what we are missing here.
Now theoretically, we could create new completion cause code
no-match-max-time, and partial-match-maxtime to differentiate them from
the ones that would have been generated during a silence/endpointing.

Now If I understand Andrew, he is refering to no-match-max-time as
Recognition-Timeout, which is fine by me, but question if it is actually
necessary for the differeniation. Coz, I am thinking if we want to
different no-match-maxtime(andrew's proposed recongition-timeout), and
success-maxtime(already defined), then we should also define
partial-match-maxtime, which has a higher probablity of occuring than
success-maxtime :-))

What do you think,
Sarvi 

     -----Original Message-----
     From: Shanmugham, Saravanan 
     Sent: Thursday, November 10, 2005 12:51 PM
     To: Shanmugham, Saravanan; Dave Burke; Andrew Wahbe; IETF 
     SPEECHSC (E-mail)
     Subject: RE: [speechsc] VoiceXML maxspeech timeout not 
     implementable withMRCPv2
     
     I just re-read this whole description and came to a 
     different conlcusion.
     
     When a recongizer is started and enough speech has been 
     collected to be able to process.
     
     The match conditions for the spoken speech and grammar 
     matching upto that point can be one of the following
        no-match
        partial-match
        complete-match
     You could go one step further and say a complete-match can 
     be of 2 sub-classes on further grammar possibilities(Is 
     there value to doing this. My thinking is not, Any thoughts)
        complete-match-with-more-possibilities
        Complete-match-with-no-more-possibilities
     
     Theoretically speaking, no-match could be decided the 
     moment that the speaker speaks something that does not 
     match anything, which could be even the first word.
     But, if I understand right, most commercial recognizers 
     today don't match the speech as they are spoken, but 
     rather wait for end-pointing/some-silience or a timer 
     before doing the matching.
     
     NOW, walking through what happens during a non-hotword 
     RECOGNIZE operation.
     
     The Recognition-Timer is started right at the beginning of 
     the RECOGNIZE operation.
     
     When silence/enpoint happens they take the speech 
     collected upto that point, and match it with the grammar 
     and do the following.
        1. If there was NO match - they generate   "no-match 
     001" completion cause code.
        2. If there was partial-match - They start the 
     Speech-Incomplete-Timer
        3. If there was complete-match(both sub types) - They 
     start the Speech-Complete-Timer.
     
     Now lets look at the cases of the different timers expiring.
     
     Speech-Incomplete-Timer expires, we return partial-match 013 
     When Speech-Complete-Timer expires, we return "success" 000.
     When Recognition-Timer expires we have multiple 
     possibilities based on the grammar match condition.
         1. no-match 001
         2. partial-match 013
         3. succcess (which is differentiated as success-maxtime 008)
     
     So I don't see what we are missing here.
     Now theoretically, we could create new completion cause 
     code no-match-max-time, and partial-match-maxtime to 
     differentiate them from the ones that would have been 
     generated during a silence/endpointing.
     
     Now If I understand Andrew, he is refering to 
     no-match-max-time as Recognition-Timeout, which is fine by 
     me, but question if it is actually necessary for the 
     differeniation. Coz, I am thinking if we want to different 
     no-match-maxtime(andrew's proposed recongition-timeout), 
     and success-maxtime(already defined), then we should also 
     define partial-match-maxtime, which has a higher 
     probablity of occuring than success-maxtime :-))
     
     What do you think,
     Sarvi 

          -----Original Message-----
          From: [email-masked] 
          [mailto:[email-masked]] On Behalf Of 
          Shanmugham, Saravanan
          Sent: Monday, November 07, 2005 10:54 AM
          To: Dave Burke; Andrew Wahbe; IETF SPEECHSC (E-mail)
          Subject: RE: [speechsc] VoiceXML maxspeech timeout not 
          implementable withMRCPv2
          
          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

               > 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/msg0
               1510.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/msg0
               1501.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/msg0
               0560.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

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

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