Subject: MRCPv2 (was RE: [mediactrl] SIP Control Framework and IVR Package)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 14 Feb 2006 18:23:37 GMT

I would offer it would be foolish (stupid?) for MxML to do anything other than proxy MRCPv2.  Why?  Because if all you want is ASR in a call flow, then I would offer that VoiceXML is a MUCH better vehicle for that.  If you want low-level ASR/TTS/SI/SV control, like making application decisions on n-best confidence et al., then all MxML would do is translate MRCPv2 commands.  That translation is most likely to be wrong, error prone, and always behind the capabilities of the MRCPv2 servers.

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shtirmer, Gene
Sent: Thursday, February 09, 2006 3:33 PM
To: Mark Scott; Dave Burke; McGlashan, Scott; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package

Mark, thanks for your e-mail.  I commented inline...
 
I am still thinking about Dave Burke's comment earlier this week regarding modularizing the media server control protocol.  In general, I like the idea of having packages: some could be mandatory, others could be optional.  So, VoiceXML syntax could be defined as a package (as it was started to in the IVR package), as well as MxML type syntax could be defined as one or more additional packages.  But it seems that making VoiceXML package a mandatory part of a media control protocol would be an overkill, since it is rather complex and heavy-footed and actually has significant gaps in some media control areas.  
 
Of course, posing the question this way would re-focus our discussion from the question of where a VoiceXML Interpreter belongs, on the media server or app server, to which packages in the media control protocol should be mandatory and which ones could be optional.  Maybe this is better way to go forward from here.
 
Regards,
Gene

________________________________________
From: Mark Scott [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 1:19 AM
To: Dave Burke; Shtirmer, Gene; McGlashan, Scott; Chris Boulton; [email-masked]
Subject: RE: [mediactrl] SIP Control Framework and IVR Package
[snip]

While the apparent firmness of H.248 as the Mp protocol unfortunately seems to prevent the IMS MRFC/MRFP separation from being applied exactly as it is described here, it is our belief that the separation describes above will ultimately prove to be the correct one, regardless of where exactly the lines are drawn.  But is it really a deal-breaker if the best IMS MRF implementations are distributed solutions of multiple elements that co-ordinate using standards-based protocols like MSML/MSCML/MSCP/MRCPv2?

In terms of where we'd draw various lines, in our view, the nature of the interaction between VoiceXML and the resources it uses make VoiceXML existing purely at an application server level somewhat problematic.  This might work reasonably if VoiceXML could be implemented using a straightforward set of primitives exposed via some fine-grained M* protocol, but it cannot use this exclusively if it also incorporates speech processing via MRCPv1/2 - as we believe many compelling applications will.  Proxying MRCPv1/2 via the media server doesn't seem like a particularly attractive option.   
[Gene Shtirmer]  I would not necessarily accept the notion that "proxying MRCP via the media server" is never an attractive option.  The MOML spec does have speech primitives defined for example (via an optional speech package) and I see nothing wrong with, in some cases, putting an MRCP client in the MSML/MOML media server.  The application server, whether driven by the VoiceXML script or a service script built using, for example, Ubiquity's ACE, could, in turn, control the MSML/MOML media server, which, in turn, would pull in speech resources via MRCP, if they do not reside on the media server proper.  As long as the barge-in event is handled at the MRCP client level, i.e. on the media server, and does not have to propagate up to the application server for TTS to be interrupted, the barge-in response time would not suffer from this "proxying".
If a VoiceXML "application server" was in fact doing complex low-level control of a media server, while simultaneously orchestrating similarly low-level MRCPv1/2 based control of both speech recognition and speech synthesis resources, the coupling between these elements would likely be such that we'd essentially wind up arriving in the camp that I think we're trying to avoid - media servers being "built into" application servers.  The sheer amount of messaging and interaction in such an ASR/TTS-enabled case would certainly prevent the application servers from living outside the core network, as Scott alludes to.
[Gene Shtirmer]I agree that the outcome you just described is not a desirable one.  If the application server has both MSML/MOML client and MRCP client, it most likely is not a good candidate for moving outside the core network.  But, then, in that case I would rely on MOML to MRCP conversion in the media server, to abstract the app server from having to do the speech server brokering.

Another key reason that we see VoiceXML as an application server being challenging is that this will invariably give the impression that people are intended to express application logic in VoiceXML, and that it is an alternative kind of application server.  What may be less clear is that chains of application servers are quite permissible (i.e. a VoiceXML AS is not a substitute for other kinds of application servers) - and that in fact, the services offered by VoiceXML are quite desirable to application servers.  It's one thing for an application server to make use of some SIP-based protocol to have a media server play a prompt.  When that application server tries to play synthesized speech while collecting input using both DTMF and ASR simultaneously and also allowing mixed initiative to fill multiple slots with a single utterance, VoiceXML is going to start looking like a very attractive alternative to directly controlling multiple media processing elements.

This view of VoiceXML as a service that is used primarily by application servers, and the need for a protocol that supports this effectively by building further semantics beyond those in NETANN, is the primary motivation behind our participation in draft-burke-vxml-00.  This isn't inconsistent at all in our minds with a VoiceXML implementation offering draft-burke-vxml-00 on one interface, but using lower-level M* (or other) protocols in addition to MRCP on another to control underlying resources.  In fact, we've done and are continuing to do exactly this with some of our partners.

I'm hopeful that the above is useful in some way beyond being sufficiently long winded so as to increase quarterly revenues for the storage companies.  I do think the issues we're discussing here are particularly crucial, but I'm also optimistic that our views differ mostly in nomenclature as opposed to intent.

Regards,

Mark.

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.