Subject: FW: [Speechsc] Recognition Timeout

From: "Reifenrath, Klaus" <[email-masked]>
Date: Wed, 27 Apr 2005 09:28:36 -0400

Hi Brett,

below you find the discussion we had on this topic last April.

It seems this did not make it into the spec. Thanks for pointing to this
inconsistency.

I suggest to mark 003 as deprecated, but leave it in the spec for
backwards-compatibility with MRCPv1.

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: Wed, 27 Apr 2005 17:17:47 -0700

I will add text to describe the meaning of too much speech and its
consequences.

But I don't see, the need to depracate "recognition-=timeout" and leave
it in, conisdering MRCPv2 is not truly backward compatible with MRCPv1
nor was that the aim to be.  But we've kept the over model and messaging
and headers because it made sense. 
So I eill go ahead and remove the "recongition-timeout" status from the
Completion -Cause code list.

Also, if the speech did go on for too long and was expected to be
treated as an "end-of-speech" event AND if the speech spoken uptil that
point did match up with some grammar, then I would expect the return
value to be a Completion-Cause of "000" "success". If the timeout
expired and a complete match did not happen, then it should be
returning"too-much-speech-timeout". I hope we don't add a different
success cause for this case. Specially if its not a common case which I
agree it is not.

Thanks,
Sarvi

     -----Original Message-----
     From: Reifenrath, Klaus [mailto:[email-masked]] 
     Sent: Wednesday, April 27, 2005 6:29 AM
     To: 'Brett Gavagni'; Shanmugham, Saravanan
     Cc: [email-masked]
     Subject: FW: [Speechsc] Recognition Timeout
     
     Hi Brett,

     It seems this did not make it into the spec. Thanks for 
     pointing to this inconsistency.
     
     I suggest to mark 003 as deprecated, but leave it in the 
     spec for backwards-compatibility with MRCPv1.
     
     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.  

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

     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