RE: [Dmsp] RE: DMSP vs EMMA

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: dmsp@ietf.org
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:aurelien.guillou@francetelecom.com] 
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>  