Subject: Re: [Speechsc] RECOGNIZE completion-cause 003 and 008

From: "Reifenrath, Klaus" <[email-masked]>
Date: Mon, 18 Jul 2005 07:11:18 -0400

Hi Claudia,

below is an old e-mail thread on this topic.

Regards,
Klaus

-----Original Message-----
From: Pierre Forgues [mailto:[email-masked]] 
Sent: Mittwoch, 28. April 2004 14:32
To: Reifenrath, Klaus
Cc: [email-masked]
Subject: RE: [Speechsc] Recognition Timeout

OK, agreed!  This would leave the choice to the recognition engine.  The
second option would be used if there are worthwhile results to return.  

Practically speaking, we have not seen this as a common case.
Pierre

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reifenrath, Klaus
Sent: 28 avril, 2004 04:46
To: Pierre Forgues
Cc: [email-masked]
Subject: RE: [Speechsc] Recognition Timeout

Hi Pierre!

Why should the available result be discarded right away? This would only
elongate the call.
MRCP should allow two ways of handling this situation:
1) immediately return with a 008 "too-much-speech"
2) return 00x "success-maxtime" plus a recognition result In 2) the
recognizer treats the situation, when the maximum length of speech has been
reached, as if it had detected end-of-speech.

Klaus

-----Original Message-----
From: Pierre Forgues [mailto:[email-masked]]
Sent: Dienstag, 27. April 2004 20:49
To: Reifenrath, Klaus; [email-masked]
Subject: RE: [Speechsc] Recognition Timeout

We return immediately with a 008 "too-much-speech-timeout".  How about just
clarifying the documentation to reflect this?

Pierre

-----Original Message-----
From: Reifenrath, Klaus [mailto:[email-masked]]
Sent: 27 avril, 2004 04:13
To: [email-masked]
Cc: Pierre Forgues
Subject: RE: [Speechsc] Recognition Timeout

Hi group!

In case the callers utterance exceeds the maximum duration (given by the
recognition-timeout) and the recognizer has a complete match, but the caller
did not stop speaking (speech-complete-timeout did not elapse) the current
spec allows the following alternatives
1) continue recognition until speech-complete-timeout indicates that the
caller stopped speaking;
2) return completion cause "success" and a recognition result (as if
speech-complete-timeout did elapse). 
In the former case the recognition timeout is only applied to utterances
that have no match. But this seems not to go with "maxspeechtimeout" of
VoiceXML. 
In the later case the client does not get informed that only part of the
callers utterance was recognized.
 
I suggest to return a recognition result and a new completion cause
"success-maxtime" (compare recorder completion causes in 10.4). Either
"too-much-speech-timeout" or "recognition-timeout" would become obsolete. 

Klaus

-----Original Message-----
From: Pierre Forgues [mailto:[email-masked]]
Sent: Montag, 19. April 2004 19:04
To: Reifenrath, Klaus
Cc: [email-masked]
Subject: RE: [Speechsc] Recognition Timeout

Klaus,

In our case, when this timer expires, we never have a match.  The 003
recognition-timeout and 008 too-much-speech-timeout are equivalent and
ambiguous it seems.  In this case, we return a 008 too-much-speech-timeout
since in our case we don't produce a match.

Pierre

-----Original Message-----
From: Reifenrath, Klaus [mailto:[email-masked]]
Sent: 19 avril, 2004 11:50
To: Pierre Forgues
Cc: [email-masked]
Subject: RE: [Speechsc] Recognition Timeout

Hi Pierre,

this is inline with my understanding of the spec.

If the timer expires and there is no match, completion code 003
(recognition-timeout) should be returned, right?
If the timer expires and there is a match, completion code 008
(too-much-speech-timeout) along with a recognition result is returned? 

Klaus

-----Original Message-----
From: Pierre Forgues [mailto:[email-masked]]
Sent: Montag, 19. April 2004 16:36
To: Reifenrath, Klaus; [email-masked]
Subject: RE: [Speechsc] Recognition Timeout

Hi Klaus,

The definition is indeed a bit ambiguous.  It is the timer that is started
when START-OF-SPEECH event is generated by the server.  It is indeed used to
specify the maximum duration of an utterance.  

Pierre
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reifenrath, Klaus
Sent: 19 avril, 2004 07:51
To: [email-masked]'
Subject: [Speechsc] Recognition Timeout

The definition of the recognition-timeout header field could be more precise
about when the timer is started. Is the timer started when START-OF-SPEECH
is generated by the server or when RECOGNIZE/RECOGNITION-START-TIMERS is
send by the client? In the former case the parameter specifies the maximum
period of time for the utterance and maps nicely to the property
maxspeechtimeout in VoiceXML or the attribute babbletimeout in SALT. In the
later case it would be equivalent to the attribute maxtimeout in SALT.

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: "Shanmugham, Saravanan" <[email-masked]>
Date: Sun, 24 Jul 2005 22:40:26 -0700

I think see the problem.

I have made the following changes to the Recognizer Completion-Cause.

Changed speech-incomplete-timeout to "success-maxtime" as suggested by
Klaus, and meaning that there was a full match but the user continue to
speak and the recongition timeout expired.

Added a new Completion-Cause "013 partial-match" which is returned if
"Recognition timeout expired before there was a full match. But whatever
was spoken till that point was a partial match to one or more grammars."

I then updated Recognition-Timeout to address another problem relating
to timeouts of hotword RECOGNIZE operations.  "RECOGNIZE in hotword mode
completed without a match due to a recognition-timeout".

Thanks,
Sarvi

     -----Original Message-----
     From: Claudia Daboul [mailto:[email-masked]] 
     Sent: Tuesday, July 19, 2005 3:47 AM
     To: Shanmugham, Saravanan; Reifenrath, Klaus
     Cc: David R Oran; [email-masked]
     Subject: Re: [Speechsc] RECOGNIZE completion-cause 003 and 008
     
      > Recognition-timeout - means there was a partial match 
     but the user  > stopped speaking in the middle and a mid 
     speech timeout happenned.
     
     But in this case it would be the speech-incomplete-timeout 
     that would apply and according to the definition of that 
     header-field a nomatch event should be returned when it 
     expires and there is only a partial
     (incomplete) match of the grammar.
     
      > Too-much-speech-timeout means the user continued to 
     speak for too long  > but everything that was spoken until 
     the timeout does match a grammar.
     I think this would be what Klaus calls the 
     "success-maxtime" event, (which is not yet part of the 
     spec) and which would come together with a valid 
     recognition result, or did I get that wrong Klaus?

     Shanmugham, Saravanan wrote:
     > 
     > No-Match - means there was no match at all 
     Recognition-timeout - means 
     > there was a partial match but the user stopped speaking 
     in the middle 
     > and a mid speech timeout happenned.
     > Too-much-speech-timeout means the user continued to 
     speak for too long 
     > but everything that was spoken until the timeout does 
     match a grammar.
     > Sarvi
     >      From: [email-masked] 
     >      [mailto:[email-masked]] On Behalf Of 
     Claudia Daboul
     >      Sent: Friday, July 15, 2005 1:31 PM
     >      To: David R Oran
     >      Cc: [email-masked]
     >      Subject: Re: [Speechsc] RECOGNIZE completion-cause 
     003 and 008
     >      
     >       > I'll take a whack. 003 says that the recognizer didn't 
     >      see anything  > that matched an active grammar before the 
     >      timer ran out. 008 says the  > recognizer got an utterance 
     >      that matched the grammar but the user  kept  > babbling on 
     >      and didn't stop so the match is probably bogus.
     >      
     >      Do you mean that for example when the grammar understands 
     >      "yes" or "no" 
     >      and the caller says "yes, but blah blah blah..." I would 
     >      get 008, but if he just says "blah blah blah..." I 
     would get 003?
     >      
     >      I think in both cases it would make more sense to return 
     >      001 for no-match. More generally if the recognizer has 
     >      determined that the utterance could not have matched the 
     >      grammar, even if the recognition-timeout would have been 
     >      higher, it should return the no-match code.
     >      Only if this can't be determined, either because the 
     >      recognizer doesn't process the cut off utterance, or 
     >      because it determined that the utterance did indeed match 
     >      the grammar until it was cut off, the 003 (or
     >      008) should be returned.
     >      
     >      
     >      David R Oran wrote:
     >      > 
     >      > On Jul 15, 2005, at 7:43 AM, Claudia Daboul wrote:
     >      > 
     >      >> The spec defines the following completion-causes for 
     >      the RECOGNIZE 
     >      >> request
     >      >>
     >      >> 003          recognition-timeout
     >      >>                                    RECOGNIZE completed 
     >      without a match
     >      >>                                    due to a 
     >      recognition-timeout and
     >      >>
     >      >> 008           too-much-speech-timeout
     >      >>                                    RECOGNIZE request 
     >      terminated  because
     >      >>                                    speech was too long.
     >      >>
     >      >> The recognition timeout parameter is explained 
     as follows:
     >      >>
     >      >> Recognition Timeout
     >      >>
     >      >>    When recognition is started and there is no match 
     >      for a certain
     >      >>    period of time, the recognizer can send a 
     >      RECOGNITION-COMPLETE  event
     >      >>    to the client and terminate the recognition 
     >      operation. It is the
     >      >>    timer that is started when START-OF-SPEECH event is 
     >      generated by  the
     >      >>    resource and specifies the maximum duration of the 
     >      utterance. When
     >      >>    this timer expires the recognition request would 
     >      complete with a
     >      >>    status code of "008 too-much-speech-timeout". The 
     >      recognition-
     >      >>    timeout header field sets this timeout value. 
     The value is in
     >      >>    milliseconds. The value for this field ranges from 0 
     >      to MAXTIMEOUT,
     >      >>    where MAXTIMEOUT is platform specific. The default 
     >      value is 10
     >      >>    seconds. This header field MAY occur in RECOGNIZE, 
     >      SET-PARAMS or
     >      >>    GET-PARAMS.
     >      >>
     >      >>
     >      >> I am wondering if there is any difference between 
     >      completion-causes
     >      >> 003 and 008. Can anybody clarify this?
     >      >>
     >      > I'll take a whack. 003 says that the recognizer didn't 
     >      see anything 
     >      > that matched an active grammar before the timer ran out. 
     >      008 says the 
     >      > recognizer got an utterance that matched the grammar but 
     >      the user  
     >      > kept babbling on and didn't stop so the match is 
     probably bogus.
     >      >> Claudia
     
     --
     Dr. Claudia Daboul
     IBP UK (Limited)
     Luetkensallee 19
     22041 Hamburg
     Tel.: +49 (40) 3172541
     Fax.: +49 (40) 3172547
     E-mail: [email-masked]