Subject: [mediactrl] The Role of VoiceXML, and How to Use It

From: "Burger, Eric" <[email-masked]>
Date: Tue, 14 Feb 2006 15:46:40 GMT

VoiceXML absolutely, positively MUST be part of the media server
interface.  The whole point of the applications and services
infrastructure, and why we have the separation of application logic from
user interface rendering, demands such an interface.

That said, VoiceXML MUST NOT be the only interface for IVR.  In the
early days of the SIP-controlled media server, my position was that
VoiceXML was for IVR and MSCML was for conference control.  If you ever
wanted to do IVR, you would have to use VoiceXML.  Well, guess what?  A
bunch of our application developers said, "All I want to do is play one
prompt and collect a PIN.  I do NOT want all the overhead and complexity
of VoiceXML."  Over my objections, we put <play> and <playcollect> into
MSCML.  For better or worse, a lot of folks like that model.

We MUST NOT take a giant leap backwards.  We MUST have a light-weight
IVR mechanism.

How can we do this?  I would refer people to RFC 4240.  Purity and
proper engineering, separating conference control from complex IVR,
using established, proven, working SIP mechanisms, is my vote for the
way to go. 

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

---

From: "Jeff Haynie" <[email-masked]>
Date: Tue, 14 Feb 2006 18:17:10 GMT

Dave Burke deserves credit for this, but one option we've talked with a
couple of people would be to create a profile for VoiceXML media servers
(as well as other profiles potentially) that would allow you to create
the interfaces for an application/IVR standpoint but not bring in the
entire baggage of capabilities that aren't required.

This might give you something better than "yet another lightweight IVR
language" and be a common way of gaining the larger community advantage
of VoiceXML (Like tools, reusable applications/modules, certification,
interoperability, etc).

Jeff

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Burger,
Eric
Sent: Tuesday, February 14, 2006 10:55 AM
To: [email-masked]
Subject: [mediactrl] The Role of VoiceXML, and How to Use It

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

---

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

We tried this.  You can't do it.  For one thing, there is NO WAY to
avoid having a FULL ECMAscript capability.  There really isn't anything
to take out.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeff
Haynie
Sent: Tuesday, February 14, 2006 1:26 PM
To: [email-masked]
Subject: RE: [mediactrl] The Role of VoiceXML, and How to Use It

Jeff

---

From: "Jeff Haynie" <[email-masked]>
Date: Tue, 14 Feb 2006 22:17:20 GMT

Eric,

"You can't do it" is a pretty strong statement about a fairly broad
topic.

You *can* certainly do it for a number of reasons both technical and
product/business wise.  You may choose NOT to do it for a number of
reasons - both logical and irrational - and that's up to each person
interested in this topic.  I'm not sure that one opinion, use case, or
architectural pre-disposition should warrant a blanket direction.

Also, you could have a number of options here for a variety of scenarios
- I can see both sides of the equation in this debate and I could
support both for different reasons.  Good architecture can allow a
variety of scenarios to take place, but it might also (sometimes
unknowingly) disallow others.

I can also see a world where quad-core processors on common off the
shelf Pentium hardware and intelligent software might offer a different
set of constraints or opportunities (some might read that as threat,
too) from an architectural approach.

Also, with RFC 4240 - with its simplicity (which I enjoy) also comes
scalability issues in certain uses - which makes it not a "one size fits
all" blanket approach.  If you were in a VoiceXML app doing 150 audio
prompts per call with hundreds on concurrent calls - one probably
wouldn't choose this approach.  Like wise, I see a similar problem with
my experience with MSCML.  While one approach works for certain use
cases, it might not work for others.

Jeff

-----Original Message-----
Sent: Tuesday, February 14, 2006 1:34 PM

-----Original Message-----

Jeff

---

From: "Burger, Eric" <[email-masked]>
Date: Wed, 15 Feb 2006 07:33:04 GMT

What would one "take out" and leave it based on VoiceXML and not have it
look essentially like the existing IVR-'lite' markups?  The MSCP
proposal, for example, has results flying in SIP instead of HTTP.  I
would offer that is not a correct VoiceXML model.  This is because that
model results in media server messages sometimes being transported in
HTTP and sometimes in SIP.  I do not see that as an improvement.

Also, help me understand: does the statement below mean you would not
use VoiceXML for a script with 150 audio plays?  Why not?  If that is
what the statement means, I would offer the two order of magnitude
reduction in network traffic and the amortization of the browser context
across the plays make that an ideal use.  Did I miss something?

-----Original Message-----
Sent: Tuesday, February 14, 2006 5:26 PM

Eric,

Jeff

-----Original Message-----

Jeff

---

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 15 Feb 2006 09:50:38 GMT

The MSCP proposal promotes use of a dedicated control channel not SIP
for passing control messages between AS and MS. See Section 7 "Transport
Channel" in
http://www.ietf.org/internet-drafts/draft-mcglashan-mscp-01.txt. The
next version of MSCP will refer to the control channel in
http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework-
00.txt. 

VoiceXML allows various models for data passing:

- pass data to/from document server when retrieving/obtaining a document
(<submit namelist="data1 data2">)
- pass data to/from invoker  (e.g. input from invoker in connection
object and passing it back to invoker with a dialog <exit
namelist="data1 data2"/>)
- pass data to/from separate data source (e.g. <data namelist="data1
data2"/>)

I think there is increasing recognition in VoiceXML that data should be
separated from the presentation (encoded in VoiceXML documents) since
this faciliates a more efficient data-driven approach (i.e. presentation
documents are models and data is retrieved independently to drive
execution of these presentation models).   

Scott

-----Original Message-----
Sent: Wednesday, February 15, 2006 08:42

-----Original Message-----

Eric,

Jeff

-----Original Message-----

Jeff

---

From: "Jeff Haynie" <[email-masked]>
Date: Wed, 15 Feb 2006 19:28:50 GMT

OK, point of clarification:

I absolutely see 150 audio plays being perfectly fine in VoiceXML.
Using netann to create 150 individual SIP dialogs (and thus tear them
down, etc) for each of the 150 plays in the corresponding VoiceXML
application is what I was referring to below.

However, what I'm saying is that something like (VXML):

<prompt>
    <audio src=" http://prompts.example.net/us_EN/welcome.au "/>
</prompt>

And (MSCML)

<request>
    <play prompturl="http://prompts.example.net/us_EN/welcome.au"/>
</request>

Are semantically the same thing although they have syntactic differences
in their XML sugar.

Also, something like (MSCML) :

<configure_conference ... >

And (from CCXML)

<createconference ... >

Aren't entirely much different either. I realize MSCML in someways
attempted to solve something slightly different than VoiceXML/CCXML -
but largely the subset of the language might be able to be re-used.

I'd rather see some more understanding of the requirements we're after
and use cases and then looking at existing capabilities and languages
that could be extended than having
yet-another-IVR-conference-control-application language developed -
regardless of how and where its transported and executed.

-----Original Message-----
Sent: Wednesday, February 15, 2006 2:42 AM

-----Original Message-----

Eric,

Jeff

-----Original Message-----

Jeff