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

From: Baggia Paolo <[email-masked]>
Date: Fri, 15 Jul 2005 15:36:18 +0200

Dear Claudia,

I completely agree with David.

The "008" is related to what VoiceXML 2.0 call:
"maxspeechtimeout" that is defined at:
http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml6.3.2 as:

"The maximum duration of user speech. If this time elapsed before 
the user stops speaking, the event "maxspeechtimeout" is thrown. 
The value is a Time Designation (see Section 6.5). 
The default duration is platform-dependent."

The "003" is the "timeout" for generating "noinput" event.
The user didn't speak at all.

Paolo Baggia, Loquendo.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of David R Oran
Sent: Friday, July 15, 2005 2:14 PM
To: Claudia Daboul
Cc: [email-masked]
Subject: Re: [Speechsc] RECOGNIZE completion-cause 003 and 008

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
>
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
>

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

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Claudia Daboul <[email-masked]>
Date: Fri, 15 Jul 2005 22:40:21 +0200

> The user didn't speak at all.

No, in the MRCP v2 spec the no-input-timeout has code "002".

I agree that the recognition-timeout parameter in MRCP v2 corresponds to 
the maxspeechtimeout in VoiceXML 2.0, but in VoiceXML there is only one 
event, namely the maxspeechtimeout event, which can be returned when 
this timeout has elapsed. In contrast it seems that in MRCP there are 
two different possible return codes corresponding to this same timeout.