Subject: RE: [Dmsp] RE: DMSP vs EMMA

From: "Ferrans James-JFERRAN1" <[email-masked]>
Date: Fri, 14 Apr 2006 10:50:08 -0400

Aurelien: DSMP messages are really closed to VoiceXML events / commands (NOINPUT, NOMATCH,...). Multimodal services can be done without VoiceXML browser (without VXML scripts) with only simple ASR/TTS resources (only launch recognition or synthesis process). Do you plan to open / enlarge the DMSP protocol to "simple" Voice server (ASR+TTS without VoiceXML) ?   

I believe you already can drive the Voice Browser at a conceptual level beneath a VoiceXML dialog.  One way to do this is to send the Voice Browser a new extremely simple VoiceXML document for each prompt-and-collect, using CMD_LOAD_SRC.  The GUI Browser constructs this document from a prompt and a speech recognition grammar (by URL or by providing complete text).  It inserts the prompt and the grammar into a standard VoiceXML template that consists of a single <form> and a single <field>, then sends the resulting document via the CMD_LOAD_SRC.  At the start of the application, and after each speech recognition attempt, the GUI Browser creates the next prompt-and-collect document to listen for and sends it to the Voice Browser.  This creates a bit more message traffic though.
 
As far as DMSP is concerned, the Voice Browser doesn't even have to have a VoiceXML interpreter.  You could modify the above approach to have the GUI Browser send the bare prompt and speech grammar via CMD_LOAD_SRC in some other format than VoiceXML.  Then the Voice Browser can use these directly for the next prompt-and-collect without bothering with VoiceXML interpretation.  The Voice Browser and GUI Browser still need to communicate in terms of documents, dialogs, and fields, but each document has just one dialog in it, and that dialog has one field.  I suppose you could even put something like "run <url>" or even "prompt-collect #123456" in the CMD_LOAD_SRC.
 
I think our group needs to have the general principal that DMSP should know as little as possible about the voice dialog language layered on top of it, so that it can evolve (e.g., to VoiceXML 3.0) independently, and so that your use-case could be supported.
 
Having said all this, there are major interoperability issues if you use a proprietary approach instead of the standard one.  The same economic forces that made the industry adopt VoiceXML are at work here too, so the great majority of DMSP clients and DMSP servers will layer VoiceXML on top of DMSP.
 
Jim Ferrans

________________________________

From: Engelsma Jonathan-QA2678 
Sent: Friday, April 14, 2006 9:05 AM
To: GUILLOU Aurelien RD-SIRP-LAN
Cc: [email-masked]
Subject: [Dmsp] RE: DMSP vs EMMA

Hello Aurelien,
 
See my response embedded below.  Thanks for reading the draft and providing your input.
 
-jre
 
ps - I've cc'd the dmsp list on my response, as there are others there who have made similar suggestions.

________________________________

From: GUILLOU Aurelien RD-SIRP-LAN [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 4:17 AM
To: Engelsma Jonathan-QA2678
Subject: DMSP vs EMMA

Hi Jonathan, 

I've read the specification of the EMMA at the W3C, and I wonder how we can insert the EMMA messages in the 
DMSP protocol. My view is that EMMA should describe the recognition results for example from the server to the client in 

a DSMP response MESSAGE. Is DSMP should really encapsulates EMMA messages ?  

JRE: Yes.  EMMA messages could be carried as "extended recognition results".  See section 4.2.2.9 in the spec. 

DSMP messages are really closed to VoiceXML events / commands (NOINPUT, NOMATCH,...). Multimodal services can be done without VoiceXML browser (without VXML scripts) with only simple ASR/TTS ressources (only launch recognition or synthesis process). Do you plan to open / enlarge the DMSP protocol to "simple" Voice server (ASR+TTS without VoiceXML) ?   

JRE: We intentionally designed the protocol to operate at the dialog level, as this helps keep the protocol amenable to implementations that involve low bandwidth, high latency networks and resource constrained clients.   That said, you aren't the first one to bring this point up both on the mailing list and in offline discussions.  If there are additional features required by the particular multimodal use cases you have in mind that aren't already adequately addressed by MRCP,  please share them on the dmsp list.    We would like to maintain support for dialog level control messages, but at the same time are open to supporting other configurations as well, as long as we can keep the message set and associated state machines simple and compact. 

Thanks for your response, 
Best Regards. 
Aurélien. 

Aurélien Guillou 
France Télécom 
Recherche & Développement 
SIRP/SIS/SIT 
Ingénieur R&D 
2, avenue Pierre Marzin 
22307 LANNION Cedex 
Tel : + 33 (0)2 96 05 94 26 
Fax : + 33 (0)2 96 05 18 49 
http://www.francetelecom.com/rd <http://www.francetelecom.com/rd>  

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

---

From: "Ferrans James-JFERRAN1" <[email-masked]>
Date: Fri, 14 Apr 2006 14:01:56 -0400

I strongly agree.
 
An interesting thought experiment would be to consider if CMD_LOAD_SRC
could contain an MRCP request and the result be an MRCP response.
According to our studies this is quite inefficient, but if it were
possible to (mis)use DMSP in this way, that would indicate that DMSP
isn't making assumptions about its payload, and that we're not
duplicating MRCP's functionality.
 
Jim

From: Chris Cross [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 11:47 AM
To: [email-masked]
Subject: Re: [Dmsp] RE: DMSP vs EMMA

> DSMP messages are really closed to VoiceXML events / commands 
> (NOINPUT, NOMATCH,...). Multimodal services can be done without 
> VoiceXML browser (without VXML scripts) with only simple ASR/TTS 
> ressources (only launch recognition or synthesis process). Do you 
> plan to open / enlarge the DMSP protocol to "simple" Voice server 
> (ASR+TTS without VoiceXML) ?   

I agree with other's responses to Aurelien. However, we must take care
to not duplicate the function of MRCP. The domain we're working in is
the sychronization of modalities within a dialog. I think if all an
application wants to do is speech enable itself through a low level
speech engine interface then MRCP may be the correct route for that.

chris cross