Subject: Re: [Speechsc] VoiceXML inputmodes property

From: RJ Auburn <[email-masked]>
Date: Wed, 6 Sep 2006 09:42:39 -0400

Folks,

Was this issue ever addressed? I agree with Patrizio that we need a  
better solution here.

Thanks,

	RJ
---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Apr 3, 2006, at 10:27 AM, Bergallo Patrizio wrote:

>
> 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
> 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 = "Input-Mode" ":" modes CRLF
> modes = "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 = "Input-Type" ":" inputs CRLF
> inputs = "speech" / "dtmf" / "all"
>
> 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
> <mailto:[email-masked]>[email-masked].  
> Thank you
> <http://www.loquendo.com>www.loquendo.com
> ================================================
>
> _______________________________________________
> 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: "Dave Burke" <[email-masked]>
Date: Sun, 10 Sep 2006 20:12:04 +0100

As I recall, the thread was left with the assumption that a VoiceXML 
interpreter context would only activate the grammar types according to its 
inputmodes property. This addresses Patrizio's issues except for:
1. How does the VoiceXML interpreter know the grammar types without 
introspection?
2. How can a grammar be activated without input for that mode being 
activated?

Certainly, 2 is a VoiceXML-oddity and in practice a rare edge case - I took 
the pragmatic view to just ignore it.  That leaves 1 and there are some 
solutions e.g. perform a partial download of the grammar to check the mode 
attribute and cache that type subject to HTTP rules; or perform a HEAD and 
look for a custom parameter on the MIME type to indicate the mode; or 
download the entire grammar and use DEFINE-GRAMMAR or serve up via internal 
Webserver. Of course, none are particularly satisfying.

I am certainly fine with adding an Input-Mode header field and removing the 
sentence in section 9 "By analyzing the grammars that are activated by...". 
In this case, note that the Input-Mode header is ignored for dtmfrecog 
resources and a value of dtmf for speechrecog resources not supporting DTMF 
results in a 404 Illegal Value for Header.

Dave

----- Original Message ----- 
From: "RJ Auburn" <[email-masked]>
To: "Bergallo Patrizio" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 06, 2006 2:42 PM
Subject: Re: [Speechsc] VoiceXML inputmodes property

>> some months ago there was a discussion on VoiceXML 'inputmodes'  property
>> - When both synthesis and recognition resources are involved in the  same
>> property, VoiceXML client can only abort RECOGNIZE method and take  some
>> action (raise an error event? nomatch, noinput or others). On the  other
>> 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
>> VoiceXML client receives RECOGNITION-COMPLETE event only, and if  result
>> - When external grammars are involved in VoiceXML pages, VoiceXML  client
>> 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
>> input is always expected to be DTMF. This property does not control  the
>> activation of grammars. For instance, voice-only grammars may be  active
>> Alternatively, it is possible to reuse and extend the input type  header,
>>
>> in the following way:
>>
>> Input Type
>>
>> <mailto:[email-masked]>[email-masked].  Thank you

---

From: RJ Auburn <[email-masked]>
Date: Mon, 11 Sep 2006 04:57:40 -0400

I would strongly like to add the Input-Mode header as there are all  
sorts of other problems that can arrive when you start the double  
download approach.

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Sep 10, 2006, at 15:12 PM, Dave Burke wrote:

> As I recall, the thread was left with the assumption that a  
> VoiceXML interpreter context would only activate the grammar types  
> according to its inputmodes property. This addresses Patrizio's  
> issues except for:
> Certainly, 2 is a VoiceXML-oddity and in practice a rare edge case  
> - I took the pragmatic view to just ignore it.  That leaves 1 and  
> there are some solutions e.g. perform a partial download of the  
> grammar to check the mode attribute and cache that type subject to  
> HTTP rules; or perform a HEAD and look for a custom parameter on  
> the MIME type to indicate the mode; or download the entire grammar  
> and use DEFINE-GRAMMAR or serve up via internal Webserver. Of  
> course, none are particularly satisfying.
>
> I am certainly fine with adding an Input-Mode header field and  
> removing the sentence in section 9 "By analyzing the grammars that  
> are activated by...". In this case, note that the Input-Mode header  
> is ignored for dtmfrecog resources and a value of dtmf for  
> speechrecog resources not supporting DTMF results in a 404 Illegal  
> Value for Header.
>
> Dave
>
> ----- Original Message ----- From: "RJ Auburn" <[email-masked]>
>> Was this issue ever addressed? I agree with Patrizio that we need  
>> a better solution here.
>>
>> Thanks,
>>
>> RJ
>> ---
>> RJ Auburn
>> CTO, Voxeo Corporation
>> tel:+1-407-418-1800
>>
>>
>>
>>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom  
>>> Italia S.p.A.
>>>

---

From: Brett Gavagni <[email-masked]>
Date: Mon, 11 Sep 2006 09:12:35 -0400

I agree with RJ, as I'm also not an advocate of the double-dip download 
approach. =)

We had a discussion a while back that listed a couple of other possible 
MRCP options of exploration to support the VoiceXML inputmodes property:
http://www1.ietf.org/mail-archive/web/speechsc/current/msg01240.html

Thanks,

Brett Gavagni 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/ 
[email-masked]

RJ Auburn <[email-masked]> 
09/11/2006 04:57 AM

To
Dave Burke <[email-masked]>
cc
[email-masked], Bergallo Patrizio <[email-masked]>
Subject
Re: [Speechsc] VoiceXML inputmodes property

                 RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800