Subject: Nice Write-up (was RE: [mediactrl] SIP Control Framework and IVR Package)

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

The nice thing about being disconnected for so long is that other people eventually say what I would say anyway.

Mark below very eloquently explains why VoiceXML belongs in the media server.  I would like to toss in another, fundamental, reason.  Namely, putting the VoiceXML browser in the media server is the embodiment of the principle of Separation of Concerns.  Specifically, applications do application logic on application servers while media servers render the user interface.  This is what enables the improvement in scale AND developer productivity.

Let us put it a different way - our goal here is NOT to put IP interfaces on TDM, or TDM-like, gear.  That was done with RFC 3235.    If you want a network version of BFV, CT-Access, or R4, use RFC 3235.  If you need that sort of interface, use that interface.

I do have slightly different views on the role of VoiceXML, which I will put into a different e-mail.

[Also on the list management side: note the use of ASCII (IETF preferred), not HTML, and trimming the message at an appropriate point.  These 20-page long e-mail trails are getting silly.]

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Scott
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

This has certainly been a very interesting E-mail thread to read through.

As I think Dave's message implies, we're really dealing with two separate issues - (1) what the appropriate logical architecture is for delivering VoiceXML/CCXML services in NGN/IMS architectures, and (2) how do we draw boxes labeled "application server" and "media server" around the elements of those architectures, and put labels like "Mp" and "Mr".

Gene's diagram from Saturday was useful to me in that it delineated VoiceXML/CCXML interpretation and processing from the media processing resources used to realize those applications.  This is a model that we strongly believe in; our view is that the companies and technologies best suited to building "soft or hard DSP" functionality and associated packaging are very different from the companies that are best at VoiceXML/CCXML interpreter technology.  Furthermore, the ideal computing platforms for "hard DSP" and for HTTP/XML/ECMAScript-centric languages like VoiceXML/CCXML are inherently different - which is likely why embedded web servers don't handle the majority of online transactions today.

As an industry, we have certainly demonstrated that these are not hard lines; many hardware-centric media server companies have put VoiceXML implementations on their products which work fine (as long as it's VoiceXML 1.0), just as a number of VoiceXML platform companies have embedded lightweight, software-based media servers that work fine too (as long as it's G.711).  I'm exaggerating somewhat, but I think that a line drawn with DOM-enabled VoiceXML 2.1 + speech on one side, and high-density complex codec transcoding on the other is a fairly clear and straight line.

Getting back to the original two issues, Scott's statement that he agrees with separation of VoiceXML/CCXML from low-level media operations, coupled with Gene's diagram showing this (albeit with somewhat different boxes) implies to me that we collectively seem to agree on (1) - though not without a few subtle nuances - but not on (2).

Our view on (2) is that with the exception of H.248 for Mp, and the absence of any consideration of VoiceXML in current specifications, the IMS architecture with the separation of MRFC and MRFP elements is a good one.  Notionally, MRFP seems to correspond quite clearly to "Soft or Hard DSPs" with some low-level interface protocol; MRFC seems to match the nature of a VoiceXML interpreter quite well.  This seems particularly true to us when you consider additional speech resources such as ASR servers and TTS servers, which are in essence additional kinds of MRFPs.  It seems logically sound for an MRFC (VoiceXML) to orchestrate a heterogeneous collection of MRFP resources in the execution of a VoiceXML page.  Indeed, when you consider the operation of speech recognition or speech synthesis, the notion of H.248 as the sole protocol for interacting with the MRFP becomes increasingly problematic - as it seems beyond doubt that MRCPv1/2 will be the protocol of choice for interacting with ASR, TTS, SI/SV, and other such services at least for the near future.

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.  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.

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.
[snip] 

--------------------------
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.