Re: [v3] Some v3 functionality suggestions and scenarios

Does goto tag in VXML, allows the transitioin to an Item of another form in
the same document using nextitem attribute?

Thanks in advance for speedy response.

Regards
Vibhu


On 8/3/06, Shane Smith <safarishane@gmail.com> wrote:
>
> Skip,
>
>
> >>1- Grammars that stop the dialog thread, and return a semantic tag to
> affect the dialog >>flow
> done and done
>
>
> >>2- Grammars that do NOT affect the dialog flow at all, but produce
> asynchronous events >>to be handled by CCXML/scXML
> Using marktime, this could be accomplished by setting marktime upon an
> utterance, performing actions on the client side, and then jumping back into
> your prompt using your marktime as a reference.  With bargeintype set to
> hotword, I imagine this would be seamless to the caller.
>
>
> >>3- Grammars that don't return semantic tags, but instead affect local
> parameters such >>as playback speed, loudness, audio file position, etc.
> Same, using marktime, though my guess would be a round trip to the
> server.  I can really see using marktime becoming ugly if we were to request
> audio volume changes and needed to handle that on the server for the
> upcoming http fetch of the audio file.  Possible, but ugly.
>
> If these changes are implemented in 3, from an IVR perspective I would
> still want to potentially provide an audio cue that the grammar was
> accepted and action taken.  Conversely, we would also potentially need an
> earcon to let the caller know they nomatched on their last spoken
> utterance.  Both of these audio cues would need to be played on top of the
> current audio stream playback, assuming these work similar to the
> bargeintype=hotword support today.  Does v3 support combining audio
> streams?  Would we be able to do this without stopping the stream playback
> as you suggest?  Otherwise, I'd end up using marktime to implement client
> side browser functionality on the server to work around those limitations v3
> is supposed to address.
>
> > 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.
> I see your point.  It could be argued that this functionality belongs in
> the application scope, simply causing the next fetch to spit out vxml that
> would make it seem as if we picked up right where we left off.  That leaves
> out client side events though, with ccxml trying to tell vxml it's time to
> pause.
>
> Cool, good info, thanks...
> -Shane Smith
>
>
>
> On 8/2/06, Skip Cave <Skip.Cave@intervoice.com> wrote:
> >
> >
> >
> >
> > 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/, 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.
> >
> >
>