RE: [v3] Some v3 functionality suggestions and scenarios

Shane,

 

My comments are interspersed with yours.

 

________________________________

From: Shane Smith

Sent: Wednesday, August 02, 2006 3:22 PM
To: Skip Cave
Subject: Re: [v3] Some v3 functionality suggestions and scenarios

 

Hello Skip, 

Interesting read... had a couple of clarifications if you don't mind.
Are there any scenarios you envision that couldn't be handled with
CCXML?  

[SC] As far as I can tell, NONE of my scenarios could be implemented in
CCXML, though it is more a problem with VXML than CCXML. Take the
scenario where the VXML script is playing a long voicemail message & an
external asynchronous event occurs (presumably detected by CCXML or
scXML). The external event could be a task completion, an inbound call,
a stock-sell threshold reached, whatever) There currently isn't any way
for CCXML to suspend the current active VXML script, save the VXML
script context, and pause the voicemail play, to make way for the user
to handle the new event. We need a way for CCXML to suspend and resume
VXML scripts without losing context. 

Assuming the active VXML script could be suspended, then the application
needs to let the user deal with the issue - acknowledge the task
completion, handle the call, interact with a different VXML script to
deal with the stock sale, etc. This means that the CCXML/scXML process
may need to start up a second VXML script to let the user deal with the
asynchronous concurrent task, leaving the original script suspended on
the context stack. After dealing with the issue, we want to have CCXML
tell the VXML browser to resume back where it left off, popping the
context stack, and continuing where it left off originally, playing the
long voicemail message in the voicemail VXML script. 

As far as I can tell, there is no way for CCXML to gracefully stop a
running VXML script without killing the browser, let alone suspend it,
with the resume state context saved automatically. And of course, there
is no current way for CCXML to tell a VXML browser to resume a certain
state after it has been suspended. 

Another limitation with current VXML, is the capability to allow a user
to spawn events or commands during a play or recognize dialog state,
without killing the ongoing dialog. For example - as before, a user is
listening to his long voicemail message. In the middle of the message
from Joe, the user decides he wants to call Joe (or send Joe an email,
etc.). The user says "Call Joe" or Email Joe to call me", or some other
command, and continues listening to Joe's message. The system should
take the command "Call Joe", spawn a concurrent process to call Joe or
send him an email, but keep on playing Joe's voicemail message without
stopping. This scheme is currently impossible in VXML today. Again it's
not CCXML's problem, its VXML's problem. 

A similar issue is when the user is listening to the long voicemail from
Joe, and he says commands like "back up 10 seconds" or, "skip to the
last 20 seconds", or 'louder' or "play faster", or "slow down". All of
these commands should affect the playback of the voicemail message, but
not stop the playback. Currently, VXML doesn't do this. As a general
rule there needs to be three different types of grammars in VXML 

1- Grammars that stop the dialog thread, and return a semantic tag to
affect the dialog flow

2- Grammars that do NOT affect the dialog flow at all, but produce
asynchronous events to be handled by CCXML/scXML 

3- Grammars that don't return semantic tags, but instead affect local
parameters such as playback speed, loudness, audio file position, etc. 

Now all of this is really a limitation on VXML, not CCXML, which is why
my message title was prefaced [v3] and not [CCXML]. 

Looking at the VXML 3.0 spec at http://www.w3.org/Voice/Group/2005/V3/
<http://www.w3.org/Voice/Group/2005/V3/> , it is clear that it is
planning to have more asynchronous capabilities than VXML 2.1 

 

Under section 1.2.2.3 of the VXML 3 spec it says:

More advanced interaction with the presentation is possible in the (VXML
3) DFP framework than is currently permitted with VoiceXML 2.0/2.1.
Consequently, VoiceXML 3.0 may be enhanced with capabilities such as: 

*	VoiceXML dialogs are cancellable 
*	VoiceXML dialogs can receive events from the flow layer during
execution. These events are exposed in the presentation markup. 
*	VoiceXML dialogs can send events to the flow layer during
execution. These events are specified in the presentation markup. 

This is a good start, but the suspend scenario I described is not
covered in the statement of new capabilities. One thing missing from
this is the capability to save the dialog state, and return back later.
There needs to be a "suspend/resume" command besides the standard "start
dialog" command from CCXML.  Hopefully this functionality will get added
as the spec matures. 

Second, 3.0 needs the capability to accept user commands (touch tone,
voice, pen, whatever) during a play or recognize state, without stopping
the play or recognize state. These asynchronous commands should be able
to send events to CCXML/scXML without affecting the dialog thread. Or,
the command could affect how the current media is being handled, or
other local effects such as "record the remainder of this call" or "mute
Joe on this conference"

As an ivr designer, I've used vxml primarily to drive the call, using it
as simply as possible, just like any other protocol.  I never really
'write' vxml apps, I write web apps that shoot out vxml instead of html.
First cardinal sin on any application under my direction is the
introduction of client side logic.  Though I've been working this way
for years, I've seen a tendency at several client sites to try and write
a client side application, instead of handling all logic on the server
side.  Time to implement, debug, maintain, and test are all shorter when
using existing web application test suites.  (currently project uses
canoo, ugly but works)  Every bit of logic can be functionally tested
separate from the vui (kinda like mvc) and only when everything works do
we pick up the phone for a real test call.  I would hate to see the vxml
spec evolve to where it required more logic on the client vxml browser
than is necessary.  All the logic gates available today in vxml are
generally shunned. 

[SC] I agree totally with you. Server side is the way to go. However
with VXML, today's CCXML server currently doesn't have enough control
over the script execution. VXML 3.0 should try and fix these issues.
It's not a problem with CCXML. 

If you're familiar with osd/osdm or apache rdc's, what we do is similar
but with all event handling done by java, and nothing but a simple
javascript function to encode all data to be passed back to the server
in a single variable.  Is vxml3 still going to be accommodating to
develop in this fashion? 

[SC] Something like what you suggest is feasible, but keep in mind that
asynchronous events will be happening on both the server side and on the
client side, at any time. Both entities (server & client) must need to
be able to handle these events. Whatever mechanism is finally used, must
efficiently deal with this fact. 

Regards,
Shane Smith


This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information.  If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments.