Subject: RE: [IPTEL] CPL-03 Comments and Questions]

From: Peter Danielsen <[email-masked]>
Date: Wed, 22 Nov 2000 10:58:45 -0600

Jonathan,

Jack Kozik forwarded some of your VoiceXML discussion
to me.  Here are some comments.

Pete Danielsen

> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> Date: Wed, 15 Nov 2000 00:06:58 -0500
> From: Jonathan Rosenberg <[email-masked]>
> To: "'Henning G. Schulzrinne'" <[email-masked]>,Jonathan Rosenberg
> <[email-masked]>
> CC: "[email-masked]'"
> <[email-masked]>,[email-masked], Peter Mataga
> <[email-masked]>
>
> I'm only a novice at VoiceXML, so any experts out there, please feel free to
> correct me.
>
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:[email-masked]]
> > Sent: Tuesday, November 14, 2000 10:42 PM
> > To: Jonathan Rosenberg
> > Cc: [email-masked]'; [email-masked]
> > Subject: Re: [IPTEL] CPL-03 Comments and Questions
> >
> >
> > In the "loading" of scripts via HTTP, is this "stacked"?
>
> No.
>
> I.e., if the
> > loaded script returns, what happens?
>
> There is no "return".

The job of a VoiceXML document is to specify a dialog to be
conducted between a voice response platform and a person.
Usually, the dialog results in the filling of a "form" of user responses
that is submitted to a web server for processing.  The web server
replies with another VoiceXML document, generated based on
the submitted form data, for the next stage of the call.

We believe the number of dynamically created documents will far
outnumber those that are static.

> > Does execution continue after the
> > invocation of the http? Is there a namespace separation (VoiceXML has
> > variables)?
>
> There can be sharing of variables, but only if those variables are defiend
> in the root voicexml document, and then only if the original doc, and the
> one just loaded, both share the same root. Otherwise, variables defined
> within script A are not in scope when script B is loaded.

The interpreter validates the response document before conducting
the dialog it contains.  If the response document is considered invalid,
an exception is thrown within the context of the first document,
which may or may not specify a handler for the exception.  If the
response document is ok, the interpreter terminates interpretation of
the first document and begins interpreting the response.

If a document does not specify a URI to submit the data to, the
interpreter terminates after the form is filled.  It is up to the interpreter's
context to decide what happens to the call (e.g. disconnect, return to
another application that has embeddded support for VoiceXML, etc.)

Associated with each session is a set of session variables.  These
are maintained by the interpreter and may be referenced by each
document encountered in the session.  Each document may have
its own set of document variables.  They are active only
during interpretation of the document in which they are declared.
They do not persist across transitions to new documents.

In most cases, call processing proceeds as described above, one
document collects data, submits it to a URI that can process the
data and return a subsequent document, with session variables being
the only client side (IVR platform) data that persists across documents.

There are two other cases worth mentioning.  One is the use of
the application root document, the other is the subdialog case.
A document may declare itself to be part of an application, which
has an application root document.  The application root document
may declare application variables that persist between documents
as long as they all belong to the same application.  The application
variables are discarded when a new document is received that
does not belong to the previous document's application.  Otherwise,
transitions between documents follows the "goto" model described
above.

The subdialog case follows a stack model.  When a subdialog is
invoked its variable environment is stacked on top of the calling
dialog. The subdialog may "return" upon completion, at which
point the calling dialog resumes.

> > Can there be random jumps from a newly-loaded
> > routine to an
> > existing subroutine?
>
> There is a notion of sub-dialogs, which are like subroutine calls.
> Sub-dialogs are always invoked by an absolute reference - that is, the URL
> of the VoiceXML script plus the name of the form within the voiceXML
> document. It's possible that this document is cached, but beyond that, there
> is little difference as to whether the sub-dialog is in a new document or
> one previously used.

The subdialog reference may be relative or absolute.

> > Can existing subroutines be replaced?
>
> Since sub-dialogs are referred to by absolute names, they can only be
> "replaced" in the sense that the VoiceXML script at the given URI is
> re-fetched (since it was not cached), and a different script is returned.

Caching control attributes within a document tell the interpreter
whether to always fetch a fresh version or to pull one from the cache, if
available.

> > What if the
> > subroutine making the http "call" itself gets replaced?
>
> Thats a good question. I don't know.

The interpreter keeps the version of the calling document in effect
when a subdialog is invoked.  If the subdialog requests a fresh
version of the calling document, it will use the fresh one, but the
previous version will be resumed when the subdialog returns.

>  What
> > happens to
> > CPL predictability if there is a loop of endless retrievals?
>
> I don't think VoiceXML interpreters have any facility for handing loops. I
> guess its up to the http server that is returning these things.

The language definition does not prevent the creation of loops either within
the document or by repetitively requesting the same document.

> > I have to admit to some queasiness to a model that looks suspiciously
> > like the old "load a new segment" model in early Intel/DOS
> > versions. (It
> > appears somewhat similar to the "load" statement in Tcl, say,
> > too, with
> > potentially some of the same unpredictability.)
>
> I suspect these issues were considered in the design of VoiceXML, but I
> personally can't comment. Anyone?
>

As mentioned earlier, an interpreter is free to do analysis of
a document that it has received and reject it by throwing an exception
within the context of the referring document.  These are generally
called "error.badfetch" exceptions, but may be extended by vendors to supply
additional information.  A document author may include an event
handler for it to specify feedback to the caller, or alternate actions to take.

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel