From speechsc-bounces@ietf.org Mon Apr 03 10:28:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQ2N-0006rp-D7; Mon, 03 Apr 2006 10:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQ2M-0006rk-5c for speechsc@ietf.org; Mon, 03 Apr 2006 10:28:10 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQ2J-0004t1-3P for speechsc@ietf.org; Mon, 03 Apr 2006 10:28:10 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 16:27:57 +0200 Received: from PTPEVS106BA020.idc.cww.telecomitalia.it ([156.54.241.223]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 16:27:57 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Subject: [Speechsc] VoiceXML inputmodes property Date: Mon, 3 Apr 2006 16:27:11 +0200 Message-ID: <01C0B9926BC410459FE9AACE49B815023F55B7@PTPEVS106BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] VoiceXML inputmodes property thread-index: AcZXKrIzRFqJTxBXTrO5pilcZXrErA== From: "Bergallo Patrizio" To: X-OriginalArrivalTime: 03 Apr 2006 14:27:57.0133 (UTC) FILETIME=[CD4E1FD0:01C6572A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0038182067==" Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --===============0038182067== Content-Type: multipart/alternative; boundary="----=_NextPart_000_163E2A_01C6573B.910EA1A0" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_163E2A_01C6573B.910EA1A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, some months ago there was a discussion on VoiceXML 'inputmodes' property implementability in MRCPv2 protocol (see http://www1.ietf.org/mail-archive/web/speechsc/current/msg01497.html). That thread was closed renaming 'START-OF-SPEECH' event in 'START-OF-INPUT', adding 'input-type' header to it and clarifying conditions under which START-OF-INPUT event has to be generated from server. However, this solution seems not so good to us, for the following reasons: - When both synthesis and recognition resources are involved in the same MRCPv2 session, START-OF-INPUT event generation causes internal SPEAK interruption. If 'input-mode' header is not conform to inputmodes property, VoiceXML client can only abort RECOGNIZE method and take some action (raise an error event? nomatch, noinput or others). On the other hand, even though only a RECOGNIZE is sent, a wrong grammar could be matched (e.g. a DTFM grammar when the input mode was set to "voice"); in this case the VoiceXML interpreter could just recover the error raising e.g. a NO-MATCH event and reprompting the question to the user; an "a priori" solution, allowing to ignore the not-requested modality, would be much more effective. - In hotword recognition, START-OF-INPUT event is never generated, so VoiceXML client receives RECOGNITION-COMPLETE event only, and if result is not conform to inputmodes property it can only raise an error event (nomatch, noinput or others) - When external grammars are involved in VoiceXML pages, VoiceXML client might not to know whether they accept vocal or dtmf input: it cannot activates grammars according to inputmode property. These are not conforming to VoiceXML specification: 6.3.6 Miscellaneous Properties inputmodes=20 This property determines which input modality to use. The input modes to enable: dtmf and voice. On platforms that support both modes, inputmodes defaults to "dtmf voice". To disable speech recognition, set inputmodes to "dtmf". To disable DTMF, set it to "voice". One use for this would be to turn off speech recognition in noisy environments. Another would be to conserve speech recognition resources by turning them off where the input is always expected to be DTMF. This property does not control the activation of grammars. For instance, voice-only grammars may be active when the inputmode is restricted to DTMF. Those grammars would not be matched, however, because the voice input modality is not active. For these reasons, we propose to add a new Recog-only header: Input Mode This header MAY be sent as part of the RECOGNIZE request in order to determines which input modality to use. It can assume following values:=20 "voice": dtmf input will be ignored from server "dtmf": speech input will be ignored from server "all": both dtmf and speech input will be analyzed from server. This is the default value if header is not specified input-mode =3D "Input-Mode" ":" modes CRLF modes =3D "voice" / "dtmf" / "all" Alternatively, it is possible to reuse and extend the input type header, in the following way: Input Type When the recognizer detects barge-inable input and generates a START- OF-INPUT event, that event MUST carry this header field to specify where the input that caused the barge-in was DTMF or speech.=20 =20 This header MAY also be sent as part of the RECOGNIZE request in order to determines which input modality to use. If its value is 'speech', dtmf input will be ignored from server. If its value is 'dtmf', speech input will be ignored from server. If its value is 'all', both dtmf and speech input will be analyzed from server. If not specified, it defaults to 'all'. input-type =3D "Input-Type" ":" inputs CRLF inputs =3D "speech" / "dtmf" / "all" Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 = webmaster@telecomitalia.it. Thank = youwww.loquendo.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_000_163E2A_01C6573B.910EA1A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
some months = ago there was a discussion on VoiceXML 'inputmodes' = property
implementability in MRCPv2 protocol = (see
http://www1.ietf.org/mail-archive/web/speechsc/current/msg01497.h= tml).
That thread was closed renaming 'START-OF-SPEECH' event = in
'START-OF-INPUT', adding 'input-type' header to it and = clarifying
conditions under which START-OF-INPUT event has to be = generated from
server.

However, this solution seems not so = good to us, for the following
reasons:

- When both synthesis = and recognition resources are involved in the same
MRCPv2 session, = START-OF-INPUT event generation causes internal SPEAK
interruption. = If 'input-mode' header is not conform to inputmodes
property, = VoiceXML client can only abort RECOGNIZE method and take some
action = (raise an error event? nomatch, noinput or others). On the = other
hand, even though only a RECOGNIZE is sent, a wrong grammar = could be
matched (e.g. a DTFM grammar when the input mode was set to = "voice"); in
this case the VoiceXML interpreter could just recover = the error raising
e.g. a NO-MATCH event and reprompting the question = to the user; an "a
priori" solution, allowing to ignore the = not-requested modality, would
be much more effective.

- In = hotword recognition, START-OF-INPUT event is never generated, = so
VoiceXML client receives RECOGNITION-COMPLETE event only, and if = result
is not conform to inputmodes property it can only raise an = error event
(nomatch, noinput or others)

- When external = grammars are involved in VoiceXML pages, VoiceXML client
might not to = know whether they accept vocal or dtmf input: it cannot
activates = grammars according to inputmode property.

These are not = conforming to VoiceXML specification:

6.3.6 Miscellaneous = Properties
inputmodes
This property determines which input = modality to use. The input modes to
enable: dtmf and voice. On = platforms that support both modes, inputmodes
defaults to "dtmf = voice". To disable speech recognition, set inputmodes
to "dtmf". To = disable DTMF, set it to "voice". One use for this would be
to turn = off speech recognition in noisy environments. Another would be
to = conserve speech recognition resources by turning them off where = the
input is always expected to be DTMF. This property does not = control the
activation of grammars. For instance, voice-only grammars = may be active
when the inputmode is restricted to DTMF. Those = grammars would not be
matched, however, because the voice input = modality is not active.

For these reasons, we propose to add a = new Recog-only header:

Input Mode

This header MAY be = sent as part of the RECOGNIZE request in order to
determines which = input modality to use. It can assume following
values:
= "voice": dtmf input will be ignored from server
"dtmf": speech = input will be ignored from server
"all": both dtmf and speech = input will be analyzed from server. This
is
the default value = if header is not specified

input-mode =3D = "Input-Mode" ":" modes CRLF
modes =3D "voice" / = "dtmf" / "all"

Alternatively, it is possible to reuse and extend = the input type header,

in the following way:

Input = Type

When the recognizer detects barge-inable input and = generates a START-
OF-INPUT event, that event MUST carry this = header field to specify
where the input that caused the barge-in = was DTMF or speech.

This header MAY also be sent as part of = the RECOGNIZE request in
order to
determines which input = modality to use. If its value is 'speech',
dtmf
input will be = ignored from server. If its value is 'dtmf', speech
input will be = ignored from server. If its value is 'all', both dtmf
and
= speech input will be analyzed from server. If not specified, = it
defaults
to 'all'.

input-type =3D = "Input-Type" ":" inputs CRLF
inputs =3D "speech" / = "dtmf" / "all"

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please send an = e_mail=20 to
<mailto:webmaster@telecomitalia= .it>webmaster@telecomitalia.it.=20 Thank you
<http://www.loquendo.com>www.loque= ndo.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

------=_NextPart_000_163E2A_01C6573B.910EA1A0-- --===============0038182067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --===============0038182067==-- From speechsc-bounces@ietf.org Thu Apr 06 16:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbCV-000192-TP; Thu, 06 Apr 2006 16:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRbCU-00018x-2G for speechsc@ietf.org; Thu, 06 Apr 2006 16:35:30 -0400 Received: from mail.voicegenie.com ([205.150.90.87] helo=voicegenie.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRbCS-0006mU-PP for speechsc@ietf.org; Thu, 06 Apr 2006 16:35:30 -0400 Received: from [205.150.90.65] (parrot.voicegenie.com [205.150.90.65]) by voicegenie.com (8.11.6+Sun/8.9.3) with ESMTP id k36KZME01719 for ; Thu, 6 Apr 2006 16:35:22 -0400 (EDT) Message-ID: <44357B7F.4040008@voicegenie.com> Date: Thu, 06 Apr 2006 16:35:11 -0400 From: Andrew Wahbe Organization: VoiceGenie Technologies User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "IETF SPEECHSC (E-mail)" Subject: [speechsc] Recognition Section Typos and Errors Content-Type: multipart/mixed; boundary="------------040305070709000306000005" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org This is a multi-part message in MIME format. --------------040305070709000306000005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some typos and errors found in the current MRCPv2 draft (09): Section 9.12: Unique is mis-spelled as "uniqe". Section 9.13: The title should be "START-INPUT-TIMERS" not "INPUT-TIMERS" (Table of Contents is wrong too). Section 9.13: The last sentence isn't quite right/clear. It says: "The recognizer resource SHOULD NOT start the timers until the client sends a START-INPUT-TIMERS method to the recognizer." This is only true if the timers were not started by the RECOGNIZE request. Section 9.9: The "Non-Hotword mode recognition" subsection gives an overview of the execution of a recognition. In addition to some typos, this section also confuses the no-input timer and the recognition timer (ie. maxspeech timer). * Typo in first sentence: "recongition" should be "recognition" * In the first paragraph, instances of "Recognition-Timer" should be changed to "No-Input Timer". (ie. "The Recognition-Timer MUST BE started at...." should be "The No-Input Timer MUST BE started at..." and "If this header is set to "false", the Recognition-Timer MUST be started..." should be "If this header is set to "false", the No-Input-Timer MUST be started..."). * Typos in point (1.): "recongizer" should be "recognizer" and "end-ofspeech" should be "end-of-speech" * There is no (correct) mention of when the Recognition-Timer should be started. Presumably this would be when the START-OF-INPUT event is sent. * There is no mention of what happens when the No-Input Timer expires (completion cause of 002 no-input-timeout) Other issues: * Both "Recognition Timer" and "Recognition-Timer" are used throughout the document. One should be used consistently; "Recognition Timer" is perhaps best. Regards, Andrew Wahbe --------------040305070709000306000005 Content-Type: text/x-vcard; charset=utf-8; name="awahbe.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="awahbe.vcf" begin:vcard fn:Andrew Wahbe n:Wahbe;Andrew org:VoiceGenie Technologies INC.;Multimodal and Development Tools adr:8th Floor;;1120 Finch Avenue W.;Toronto;ON;M3J 3H7;Canada email;internet:awahbe@voicegenie.com title:Technical Manager tel;work:(416) 736-0905 ext. 258 tel;fax:(416) 736-1551 x-mozilla-html:TRUE url:http://www.voicegenie.com version:2.1 end:vcard --------------040305070709000306000005 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speechsc mailing list Speechsc@ietf.org https://www1.ietf.org/mailman/listinfo/speechsc --------------040305070709000306000005-- From speechsc-bounces@ietf.org Sat Apr 08 23:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSQA8-0007k0-T2; Sat, 08 Apr 2006 23:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSQA7-0007jv-3r for speechsc@ietf.org; Sat, 08 Apr 2006 23:00:27 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSQA6-0004BN-O7 for speechsc@ietf.org; Sat, 08 Apr 2006 23:00:27 -0400 X-IronPort-AV: i="4.04,103,1144036800"; d="scan'208"; a="31174612:sNHT51401552" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speechsc] Issues around grammar lifetimes Date: Sat, 8 Apr 2006 23:00:25 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647029F55A5@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speechsc] Issues around grammar lifetimes Thread-Index: AcZPYaWeHb+8QdCQRt6quEJxWrCjeAMH65PQ From: "Burger, Eric" To: "Carter, Jerry" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: speechsc@ietf.org X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: speechsc-bounces@ietf.org >>> An MRCP server SHOULD retain grammars on each session created by a = DEFINE-GRAMMAR message until at least the next RECOGNIZE. It MAY retain = grammars for much longer. <<< Under what circumstance would an MRCP server *not* retain the grammar? = If you cannot think of one, and this is important, than an MRCP server = MUST retain grammars until the next RECOGNIZE. Conversely, if there are = too many circumstances when the MRCP server would not retain the = grammar, there is no point saying it should, because implementers will = do whatever they want, anyway. In general, if we have a statement that X SHOULD do Y, then in the same = paragraph one needs to enumerate when X would NOT do Y. ________________________________________ From: Carter, Jerry [mailto:jerry.carter@nuance.com]=20 Sent: Friday, March 24, 2006 11:25 AM To: speechsc@ietf.org Subject: [Speechsc] Issues around grammar lifetimes Typically, an MRCP client will issue multiple DEFINE-GRAMMAR messages = eventually followed by a RECOGNIZE.=A0 The MRCP client might reasonably = expect that the defined grammars would be available when recognition is = requested, but this does not appear to be guaranteed.=A0 Furthermore, I = do not see any notification mechanism for informing the client of which = grammars are unavailable. There does not appear to be any language in section 9 that describes = grammar lifetimes. =A0There is language in the session URI description = (section 13.7) that might relate =A0=A0=A0=A0=A0 The purpose =A0=A0=A0=A0=A0 of this scheme is to permit access to the specific = resource for =A0=A0=A0=A0=A0 the lifetime of the session with the entity storing the = resource. but this is not a normative statement requiring availability for a = session lifetime.=A0 In practice a MRCP server has a finite cache and = may support multiple parallel sessions. =A0It is unreasonable to require = that the MRCP server provision a sufficiently large cache to store all = grammars across all sessions, particularly if sessions are long and = employ large dynamic grammars.=A0 Such a requirement would render small = footprint MRCP servers impossible. If a grammar is flushed from the MRCP server's cache before RECOGNIZE, = the notification mechanism is unclear.=A0 Presumably a completion cause = of 'grammar-load-failure' would be returned.=A0 The server might want to = return a list of URIs in the message but this would violate 9.4.12 =A0=A0 Clients SHOULD NOT interpret the completion reason text.=A0 = Instead it =A0=A0 is RECOMMENDED that the reason be recorded in client logs and =A0=A0 otherwise made available for debugging and instrumentation = purposes. =20 and such an approach would need to be standardized.=A0 Additionally, a = developer would like some assurance _before_ RECOGNIZE is invoked that = all the loaded grammars are available. Because MRCP servers have finite memory and caches, it is not reasonable = to require that grammars be available on a session indefinitely after a = DEFINE-GRAMMAR. =A0We might instead require that grammars have = guaranteed availability on a session only until the next call to = RECOGNIZE; this also breaks for the same reason. Here is a solution that I believe works. (1) An MRCP server SHOULD retain grammars on each session created by a = DEFINE-GRAMMAR message until at least the next RECOGNIZE.=A0 It MAY = retain grammars for much longer. (2) DEFINE-GRAMMAR should support redefining grammars by passing the IDs = without supplying the grammar definition.=A0 The text/grammar-ref-list = media type might be appropriate for this purpose. (3) A RECOGNIZE or a DEFINE-GRAMMAR returning a completion cause of = either 'grammar-load-failure' or 'grammar-completion-failure' should = include a CRLF separated list detailing the IDs which grammars did not = load or compile. (4) The text in 9.4.11 should support DEFINE-GRAMMAR returning = 'grammar-load-failure' and 'grammar-completion-failure'. ------------------------- Under this proposal, the client might do the following: DEFINE-GRAMMAR documentLevel1 (new definition) DEFINE-GRAMMAR documentLevel2 (new definition) DEFINE-GRAMMAR formLevel1 (new definition) DEFINE-GRAMMAR fieldLevel1 (new definition) RECOGNIZE DEFINE-GRAMMAR documentLevel1 documentLevel2 formLevel1 (IDs only to = reassert continued need) DEFINE-GRAMMAR fieldLevel2 (new definition) RECOGNIZE ------------------------- Likewise, in the typical error case: DEFINE-GRAMMAR documentLevel1 (new definition) DEFINE-GRAMMAR documentLevel2 (new definition) DEFINE-GRAMMAR formLevel1 (new definition) DEFINE-GRAMMAR fieldLevel1 (new definition) RECOGNIZE