CCXML 1.0-W3C Development Guide

Home | Frameset Home

Your First Dialog

| TOC

Connecting Call Legs

Tutorial: Advanced VoiceXML Dialogs

As we have now covered the basic concept of launching a VoiceXML dialog from the CCXML 1.0 context, and have studied how we can send events from the VoiceXML back into the CCXML 1.0 wrapper, it is now time to take a look at how we can make an application that provides a bit more robustness to the equation. If we fail to load our VoiceXML dialog properly, then we are really out of luck, and our callers are left with a less-than-satisfactory call experience, right? Not if WE have anything to say about it.

Even though it goes without saying, we need to say that you should really have a solid understanding of the previious tutorials on CCXML + VXML applications before attempting this tutorial, as we are going to skip over a lot of the "basics" that were previously covered.

In this tutorial, we will:

Understand how the <dialogprepare> element works
Illustrate how we can make a dialog failure and then recover from it gracefully
Learn how to failover to alternate dialog tagets after the initial failure

Step 1: creating our initial CCXML structure

We all know how this works. An XML header, and a CCXML header that contains an XML namespace:



<?xml version="1.0" encoding="UTF-8"?>

<!-- NOTE THAT WE *MUST* DECLARE THE xmlns ATTRIBUTE -->

<ccxml version="1.0" xmlns:voxeo="http://community.voxeo.com/xmlns/ccxml">

</ccxml>

Step 2: Setting up our framework

The first thing that we want to do after getting the basic stuff in place is to add in some variable declarations that we will be using later on in our tutorial. The first thing to define is a variable for "state control," which you should be pretty familiar with by now. As we plan on launching a "bad" dialog, and then handling it in a manner that doesn't impact the caller, we will declare a variable for both our "good" and "bad" dialogs. And really soon, we will need to define a "connectionID" value for our <dialogprepare> element to leverage, so we might as well get this declared too. Last, but not least, we will want to put in place some handlers for the various errors that can occur when we launch our dialogs.



<?xml version="1.0" encoding="UTF-8"?>

<ccxml version="1.0" xmlns:voxeo="http://community.voxeo.com/xmlns/ccxml">



  <var name="mydialog" expr="''" />

  <var name="mydialog2" expr="''" />

  <var name="statevar" expr="'state0'" />

  <var name="connid" expr="''"/>



  <eventprocessor statevariable="statevar">



    <transition state="state0" event="connection.alerting">

      <accept/>

      <assign name="statevar" expr="'state1'"/>

    </transition>



    <transition state="state1" event="connection.connected">

      <assign name="connid" expr="event$.connectionid"/>

    </transition>



    <transition state="state3" event="dialog.exit">

      <log expr="'*** The dialog terminated ***'"/>

      <exit/>

    </transition>



    <transition state="state5" event="dialog.exit">

      <log expr="'*** The new dialog terminated, nice work ***'"/>

      <exit/>

    </transition>



    <transition event="error.*">

      <log expr="'Error occurred: ' + event$.reason"/>

      <exit/>

    </transition>



  </eventprocessor>

</ccxml>

Note that we also defined our "connid" variable with a value within the <transition> where the call actually connects, which will be filled with the unique "event$.connectionid" field value that is available within the "connection.connected" event. This will be important to us later on.

Step 3: Working with <dialogprepare>

The <dialogprepare> element is a very useful and powerful addition to the CCXML 1.0 specification. This element is used to get a dialog ready for actual execution via the <dialogstart> element, and allows us to take appropriate action in the event that there is a problem with the dialog requested, and to handle it before a fatal error bubbles up into the session. As mentioned, we need to "marry" any particular dialog to a specific connectionid, (or conferenceid, depending on the scenario), and this is the reason why we took care to get this taken care of in our last step. We also have to make sure that we define a "dialogid" attribute when we prepare a dialog, and since we want to launch a bad dialog right off the bat, we will use the "mydialog" variable that we defined previously for this purpose.

So, what can happen when we invoke this new element? One of two things:

The dialog will load successfully, and will spawn a "dialog.prepared" event that we can trap and handle
The dialog will not load successfully, and spawn a "dialog.notprepared" event that we can trap and handle

In the first case, we can then trap the event, and finally invoke the <dialogstart> to get the VXML dialog execution happening for our caller. Oh-ho, but in the event that the dialog fails, we can then trap the error, and switch to a secondary dialog target, without the caller ever knowing that Something Went Wrong. Which in this case, is what we want, so that we can show how it's all done. Let's take a look at the relevant code that we are going to add into our application for this contrived worst-case scenario:



<?xml version="1.0" encoding="UTF-8"?>

<ccxml version="1.0" xmlns:voxeo="http://community.voxeo.com/xmlns/ccxml">



  <var name="mydialog" expr="''" />

  <var name="mydialog2" expr="''" />

  <var name="statevar" expr="'state0'" />

  <var name="connid" expr="''"/>



  <eventprocessor statevariable="statevar">



    <transition state="state0" event="connection.alerting">

      <accept/>

      <assign name="statevar" expr="'state1'"/>

    </transition>



    <transition state="state1" event="connection.connected">

      <assign name="connid" expr="event$.connectionid"/>

      <assign name="statevar" expr="'state2'"/>

      <dialogprepare src="'bogus.vxml'" dialogid="mydialog" connectionid="connid"/>

    </transition>



    <transition state="state2" event="dialog.prepared">

      <!-- NOTE: this isnt going to happen -->

      <log expr="'*** The dialog has been prepared ***'"/>

      <dialogstart prepareddialogid="mydialog" connectionid="connid"/>

      <assign name="statevar" expr="'state3'"/>

    </transition>



    <transition state="state3" event="dialog.exit">

      <log expr="'*** The dialog terminated ***'"/>

      <exit/>

    </transition>



    <transition event="error.dialog.notprepared">

    </transition>





    <transition state="state5" event="dialog.exit">

      <log expr="'*** The new dialog terminated, nice work ***'"/>

      <exit/>

    </transition>



    <transition event="error.*">

      <log expr="'Error occurred: ' + event$.reason"/>

      <exit/>

    </transition>



  </eventprocessor>

</ccxml>

Those of you who understand the concept of foreshadowing will doubtlessly intuit that "Bogus.vxml" isn't going to load. Why, you ask? Let's take a look at the contents of the VXML file itself:



 Internet Explorer cannot display the webpage



   Most likely causes:

    * You are not connected to the Internet.

    * The website is encountering problems.

    * There might be a typing error in the address.



   What you can try:

     Diagnose Connection Problems



   * More information

Get it? There *is* no Bogus.vxml file exisitng on the webserver, so it's going to return a http 404 response code, which is just what we want. All the same, we add a <transition> in the CCXML 1.0 app that assumes that the dialog target is valid, so that we could play the dialog to the caller....but that isn't going to happen in this case. Instead, the "404" is going to tell the CCXML 1.0 interpreter that it should throw the "dialog.notprepared" event, which leaves us some room to come up with Plan B.

Step 4: Implementing Plan B

Since we have proven beyond the shadow of a doubt that we know how to write code that will break, let's now see if we can clean up our mess, by launching an alternate dialog target. Since we may find it useful to find out why the initial dialog failed, we will also add a <log> statement within the "dialog.notprepared" handler to list out some useful diagnostic information for us. From right within our "dialog.notprepared" <transition>, we can just get another dialog target prepared using the same method that we did before. You'll note that we are still using a different "dialogid" than we did for "Bogus.vxml", but we need to change the application state if we want to hit the <transition> that contains our valid <dialogstart>. And of course, this means that we will want to have new <transition> elements declared for "dialog.prepared", "dialog.exit", and the like.



<?xml version="1.0" encoding="UTF-8"?>

<ccxml version="1.0" xmlns:voxeo="http://community.voxeo.com/xmlns/ccxml">



  <var name="mydialog" expr="''" />

  <var name="mydialog2" expr="''" />

  <var name="statevar" expr="'state0'" />

  <var name="connid" expr="''"/>



  <eventprocessor statevariable="statevar">



    <transition state="state0" event="connection.alerting">

      <accept/>

      <assign name="statevar" expr="'state1'"/>

    </transition>



    <transition state="state1" event="connection.connected">

      <assign name="connid" expr="event$.connectionid"/>

      <assign name="statevar" expr="'state2'"/>

      <dialogprepare src="'Bogus.vxml'" dialogid="mydialog" connectionid="connid"/>

    </transition>



    <transition state="state2" event="dialog.prepared">

      <log expr="'*** The dialog has been prepared ***'"/>

      <dialogstart prepareddialogid="mydialog" connectionid="connid"/>

      <assign name="statevar" expr="'state3'"/>

    </transition>



    <transition state="state3" event="dialog.exit">

      <log expr="'*** The dialog terminated ***'"/>

      <exit/>

    </transition>



    <transition state="state2" event="error.dialog.notprepared">

      <log expr="'An error occurred, and the dialog was NOT prepared: ' + event$.reason"/>

      <log expr="'Attempting to launch a new dialog...'"/>

      <assign name="statevar" expr="'state4'"/>

      <dialogprepare src="'RealDialog.vxml'" dialogid="mydialog2"/>

    </transition>



    <transition state="state4" event="dialog.prepared">

      <log expr="'*** The new dialog has been prepared ***'"/>

      <dialogstart prepareddialogid="mydialog2" connectionid="connid"/>

      <assign name="statevar" expr="'state5'"/>

    </transition>



    <transition state="state4" event="error.dialog.notprepared">

      <log expr="'An error occurred, and the new dialog was NOT prepared: ' + event$.reason"/>

      <log expr="'Application will now exit...'"/>

      <exit/>

    </transition>



    <transition state="state5" event="dialog.exit">

      <log expr="'*** The new dialog terminated, nice work ***'"/>

      <exit/>

    </transition>



    <transition event="connection.disconnected">

    <log expr="'*** Connection.disconnected ***'"/>

     <exit/>

    </transition>

    <transition event="error.*">

      <log expr="'Error occurred: ' + event$.reason"/>

      <exit/>

    </transition>



  </eventprocessor>

</ccxml>

In this case the target is, in fact, valid, and the last hoop that we need to jump through is to make sure that the "preparedialogid" attribute of the <dialogstart> element matches the "dialogid" value that we declared when we prepared the dialog. That's all there is to it; we can now add an extra layer of protection to account for fetch/connectivity issues that can impact the launching of VXML dialogs from the CCXML 1.0 context.

Download the CCXML source code!

ANNOTATIONS: EXISTING POSTS

MattHenry

10/9/2007 12:20 PM (EDT)

Posting Courtesy of Mark Headd, IVR developer extraordinaire:

Because Prophecy 8.0.98.0 does not currently return an "error.dialog.notprepared" event, some additional steps are needed to obtain the results described above. I have found a workaround that might be useful in the interim, until this functionality is added to Prophecy.

When using <dialogprepare/> the current version of Prophecy will always return a "dialog.prepared" event, even if the dialog is nonexistent or can not be prepared for some other reason. When the Bogus.vxml dialog is initiated using <dialogstart/> and the "prepareddialogid" attribute, it will cause a "dialog.exit" event to land almost immediately. When an error occurs in a VoiceXML dialog, Prophecy will set an "errorReason" property on the values object that is returned to CCXML. This property will contain a description of the error that occurred. Inspecting this property can help determine if the VoiceXML dialog was fetched properly.

To implement this workaround, the transition for dialog.exit when the application is in state3 needs to be modified:

<transition state="state3" event="dialog.exit">
<if cond="event$.values.errorReason.length > 0">
<log expr="'*** There was a problem with the dialog: ' + event$.values.errorReason + '***'"/>
<send target="session.id" name="'dialogNotFetched'"/>
<else/>
<log expr="'*** The dialog terminated ***'"/>
<exit/>
</if>
</transition>

Additionally, a new transition must be added to mimic the behavior of the transition set up for an "error.dialog.notprepared" event:

<transition event="dialogNotFetched">
<log expr="'An error occurred, and the dialog was NOT fetched properly."/>
<assign name="statevar" expr="'state4'"/>
<dialogprepare src="'RealDialog.vxml'" dialogid="mydialog2"/>
</transition>

This workaround is not perfect. As far as I can tell, the errorReason property is Voxeo-specific, and there isn't any way of telling whether the error in the VoiceXML dialog occurred before the caller heard anything (i.e., a bad fetch of the dialog iteslf), or after the dialog was started (i.e., a script or semantic error later in the dialog).

That said, it might be worth examining until the full <dialogprepare/> functionality is added to Prophecy.

MattHenry

10/9/2007 12:27 PM (EDT)

To add to Mark's suggestions above, I wanted to point out that the CCXML platform not throwing the "error.dialog.notprepared" event properly is fixed in more recent versions of the Prophecy 8 software.

For those who use a local deployment of P8, you would do well to check out Prophecy version 8.0.106, which does not suffer from this limitation. For those of you who use P7 hosted, you will want to wait until we deploy P8 to the staging and production environments, as P7 doesn't really support the <dialogprepare> element fully.

~Matthew henry

mtatum111

3/13/2009 5:11 PM (EDT)

For this section of code
<transition state="state4" event="error.dialog.notprepared">
<log expr="'An error occurred, and the new dialog was NOT prepared: ' + event$.reason" />
<log expr="'Application will now exit...'" />
</transition>
- <transition state="state5" event="dialog.exit">
<log expr="'*** The new dialog terminated, nice work ***'" />
<exit />
</transition>
- <transition event="error.*">
<log expr="'Error occurred: ' + event$.reason" />
<exit />
</transition>

would it be a good idea to put

<transition state="state4" event="error.dialog.notprepared">
<log expr="'An error occurred, and the new dialog was NOT prepared: ' + event$.reason" />
<log expr="'Application will now exit...'" />
</exit>
</transition>

voxeojeff

3/13/2009 5:42 PM (EDT)

Hi Melissa,

Unless I'm mistaken, I already see an <exit/> in place at that point in the tutorial:

<transition state="state4" event="error.dialog.notprepared">
<log expr="'An error occurred, and the new dialog was NOT prepared: ' + event$.reason"/>
<log expr="'Application will now exit...'"/>
<exit/>
</transition>

Were you referring to a different transition?

Best,
Jeff Menkel
Voxeo Corporation

mtatum111

3/13/2009 5:51 PM (EDT)

Thanks, Jeff. I was actually looking inside the ccxml source code that can be downloaded. Also, it should have been <exit/> rather than </exit>. My typo on this one :)

So, basically it is just the source code that doesn't have the <exit/>

mtatum111

3/13/2009 5:52 PM (EDT)

Also, would it be a good idea to have a
<transition name="connection.disconnected">
<exit/>
</transition>

in the code...

mtatum111

3/13/2009 5:55 PM (EDT)

Actually I meant
<transition event="connection.disconnected">
<exit/>
</transition>

instead of

<transition name="connection.disconnected">
<exit/>
</transition>

It has been a long week :)

voxeojeff

3/13/2009 6:06 PM (EDT)

Hey Melissa,

Ah, I did not realize you meant the downloadable code! :-) I'll make sure this is changed, and also add in the connection.disconnected event, since it's good practice to have it there.

Thank you for bringing this to my attention.

Best,
Jeff Menkel
Voxeo Corporation

mtatum111

4/9/2009 3:23 PM (EDT)

When we execute the second <dialogprepare>, I notice that we are not passing the connectionid as an attribute. Is there a reason for this? Does it just use the one from the first <dialogprepare>?

For instance, on the first <dialogprepare> we have the following

<dialogprepare src="'Bogus.vxml'" dialogid="mydialog" connectionid="connid"/>

On the second <dialogprepare> we have the following

<dialogprepare src="'RealDialog.vxml'" dialogid="mydialog2"/>

voxeojeff

4/9/2009 3:39 PM (EDT)

Hello Melissa,

There is no reasoning behind not using a connectionid attribute with the second dialogprepare. As there is only one call leg associated with that particular example, we won't need to specify the connectionid. Also, per the W3C CCXML 1.0 specification, "src" is the only required attribute.

http://www.w3.org/TR/ccxml/#dialogprepare

Hope this helps clarify,
Jeff Menkel
Voxeo Corporation

punkin

6/7/2009 8:04 PM (EDT)

1. The source code is still not updated. No <exit/> is in <transition> event for "error.dialog.notprepared" at state4 (see mtatum111's comment).

2. <transition> for event "connection.disconnected" suggested by mtatum111 is still not in both the source code and this tutorial yet.

3. When do we need a single quote? Any guideline? I understand that we need single quotes in expr so that the runtime will treat it as a string. But I don't understand why we need a pair of single quotes inside the <send> "name" attribute. I thought this <send> element is to create a new event if it doesn't exist, and then execute it. Is it because it is a new event? If we create an event via <send>, the new event variable will exist somewhere in the memory, thus next time we don't need to have single quotes surrounding this event. Is that correct?

4. I read in somewhere ccxml is processed asynchronizedly (I hope I remember correctly). How can I know the other event is still working hard or in error? For example,

<transition state="state1" event="connection.connected">
<assign name="connid" expr="event$.connectionid"/>
<assign name="statevar" expr="'state2'"/>

<var name="delayvalue" expr=" '20 seconds ' " />
<send name="'dosomething'" target="session.id" delay="'20s'"
namelist="delayvalue"/>

<dialogprepare src="'Bogus.vxml'" dialogid="mydialog" connectionid="connid"/>

</transition>

<send> "dosomething" will generate its event while the current thread continues from "state1" to "state2." If I am in "error.dialog.notprepared" or "dialog.prepared", I don't want my application to exit before "dosomething" is not done. Similarly, I don't want to exit if either "error.dialog.notprepared" or "dialog.prepared" event is not generated. I mean, both actions (regardless of error) must be completed before exit. Is there anyway to handle this situation?

MattHenry

6/7/2009 9:16 PM (EDT)

Hello Kennis,

See replies inline:

1. The source code is still not updated. No <exit/> is in <transition> event for "error.dialog.notprepared" at state4 (see mtatum111's comment).

* Matt: Internal source code has been fixed, and will be made live in the docs shortly.

2. <transition> for event "connection.disconnected" suggested by mtatum111 is still not in both the source code and this tutorial yet.

* Matt: Internal source code has been fixed, as has he doc content: Both should be made live before the end of the week.

3. When do we need a single quote? Any guideline?

* Matt: This is essentially the difference between a ECMAScript Expression, and an ECMAScript Left Hand Side Expression value, in this case.

3a. I don't understand why we need a pair of single quotes inside the <send> "name" attribute. I thought this <send> element is to create a new event if it doesn't exist, and then execute it. Is it because it is a new event?

* Matt: I'm not sure as I understand the correlation between your three statements. For what it is worth, the send 'name' attribute expects "a ECMAScript expression that returns the name of the event", per the w3c spec.

3b.If we create an event via <send>, the new event variable will exist somewhere in the memory, thus next time we don't need to have single quotes surrounding this event. Is that correct?

* Matt: I assume that you are asking about the difference in the syntax between declaring an event to send using single quotes...

<send name="'myEvent'" target="session.id" ..../>

..versus handling the event that is sent within the <transition> -without- using singlequotes:

<transition state="someState" event="myEvent">

I'd say that this would be a pretty accurate estimate, although I don't see anything in the W3C spec that explicitly declares this to be so: The hypothesis seems programmatically logical to me. I'd suspect that this might best be answered by those on the W3C spec itself, however.

4. I read in somewhere ccxml is processed asynchronizedly (I hope I remember correctly). How can I know the other event is still working hard or in error?

<send> "dosomething" will generate its event while the current thread continues from "state1" to "state2." If I am in "error.dialog.notprepared" or "dialog.prepared", I don't want my application to exit before "dosomething" is not done.

* Matt: CCXML is indeed processed asynchronously: This can take a bit of tuning to get right, but in essence, you'd likely want to ensure that you have proper handling to keep the CCXML session active when your dialog events occur. Depending on the exact scenario, it can also be helpful to specify a <send> 'delay' with the appropriate value to have control over events that you want to send while other asynchronous actions are being handled.

Similarly, I don't want to exit if either "error.dialog.notprepared" or "dialog.prepared" event is not generated. I mean, both actions (regardless of error) must be completed before exit. Is there anyway to handle this situation?

* Matt: I think it might be best of you can describe this scenario in detail so that I can provide an on-target reply: If you have some commented CCXML code that better illustrates your concerns, this would greatly help to understand the context of this question.

Regards,

~Matthew Henry

punkin

6/7/2009 10:06 PM (EDT)

3. It took me a while to figure out why my event would not be triggered but there was no error. I was missing single quotes on "dosomething." So I am thinking:

Could we have this?

<transition state="state1" event="connection.connected">
<assign name="connid" expr="event$.connectionid"/>
<assign name="statevar" expr="'state2'"/>

<var name="delayvalue" expr=" '20s' " />
<send name=" 'dosomething' " target="session.id" delay="delayvalue" namelist="delayvalue"/>

<dialogprepare src="'Bogus.vxml'" dialogid="mydialog" connectionid="connid"/>

</transition>

<transition state="state2" event="connection.connected">
<assign name="statevar" expr="'state3'"/>

<var name="delayvalue" expr=" '10s' " />
<send name="dosomething" target="session.id" delay="delayvalue" namelist="delayvalue"/>

<dialogprepare src="'abc.vxml'" dialogid="mydialog" connectionid="connid"/>

</transition>

The first <transition> has single quotes on "dosomething" while the second doesn't.

4. I don't have a particular scenario in mind. I just wonder how to handle more than two events at the same time. The application cannot exit if either one of the events is not completed (an error occurred to one event considers task completed). I don't know if one event can be aware of another event.

MattHenry

6/7/2009 11:23 PM (EDT)

Hi again,

See answers inline once again: for further clarifications:

Could we have this?

<transition state="state1" event="connection.connected">
<assign name="connid" expr="event$.connectionid"/>
<assign name="statevar" expr="'state2'"/>
<var name="delayvalue" expr=" '20s' " />
<send name=" 'dosomething' " target="session.id" delay="delayvalue" namelist="delayvalue"/>

<dialogprepare src="'Bogus.vxml'" dialogid="mydialog" connectionid="connid"/>

</transition>

<transition state="state2" event="connection.connected">
<assign name="statevar" expr="'state3'"/>

<var name="delayvalue" expr=" '10s' " />
<send name="dosomething" target="session.id" delay="delayvalue" namelist="delayvalue"/>
<dialogprepare src="'abc.vxml'" dialogid="mydialog" connectionid="connid"/>
</transition>

The first <transition> has single quotes on "dosomething" while the second doesn't.

* Matt: I'd be doubtful that this would fly, as the spec does explicitly state that send "name" attribute does expect an ECMAScript expression which returns a character string. Is there some particular reason that this would be so important to you in your development efforts? I get the feeling that there is a "big picture" behind this, and I'd like to better understand the end goal in the interest of helping you to achieve it.

=^)

4. I don't have a particular scenario in mind. I just wonder how to handle more than two events at the same time. The application cannot exit if either one of the events is not completed (an error occurred to one event considers task completed). I don't know if one event can be aware of another event.

* Matt: Fine grained <transition> handlers that take into account the current state are the key here. One example that illustrates this in greater detail would be:

<transition state="incall_0" event="continue">
<assign name="app_state" expr="'incall_1'"/>
<send name="'continue'" target="session.id" delay="'1000ms'"/>
<dialogprepare src="'Bogus.vxml'" dialogid="mydialog" connectionid="connid"/>
</transition>


<transition state="incall_1" event="dialog.prepared">
<assign name="app_state" expr="'withinDialog'"/>
..
</transition>


<transition state="withinDialog" event="continue"/>
..
</transition>


<transition state="incall_1" event="continue">


<send name="'continue'" target="session.id" delay="'1000ms'"/>
</transition>

Some additional information that might help out is at the links below:

- http://www.w3.org/TR/ccxml/#event-handling
- http://www.w3.org/TR/ccxml/#SessionLifeCycleDiagrams

Hope this helps!

~Matthew Henry

punkin

6/8/2009 12:18 AM (EDT)

You're right. You keep emphasizing ECMAScript Expression. But I don't get it until I look <send> element. It clearly said that the "name" attribute is type of ECMAScript Expression. Now I understand why we need single quotes in this instance. I thought it applied to the event we first created but I was wrong.

Regarding #4, I will try to think of a scenario. Since the process here is asynchronous. It means it is not thread safe. It may be multi-thread accessing and it is hard to know which one is finished first. Each thread could have its own state but this thread's state is unnecessary related to another thread. A thread could branch off a few threads to handle tasks. I don't know if it is possible to place a call-back event to notify the parent thread when the child thread is done. The parent is the gate keeper to wait until all threads finish their tasks and then decide to exit.

Maybe I misunderstand the concept here; or maybe I think too complicated at this stage. Let me study more and then come back to this problem.

Thanks.

voxeoJeffK

6/8/2009 2:00 AM (EDT)

Hello,

I think its important to note that threading doesn't really apply at the CCXML layer. While threading may be happening under the covers, common CCXML applications are a single execution context. CCXML does indeed have the ability to form parent/child contexts using <createccxml>, but I don't think that's what you meant.

Events do not have a state of their own. There is always one state variable, and the application's state is solely defined by it. The purpose of state management is to allow different handling of like events. A dialog.exit is the same as the next dialog.exit. Within your CCXML you change state to appropriately handle the events as they come.

Please feel free to ask if we can help with any conceptual clarifications as you explore.

Regards,
Jeff Kustermann
Voxeo Support

punkin

6/8/2009 6:39 PM (EDT)

Thank you for the clarification.

The threading stuff may be handled in the Web development application. With all your help, I am sure I will find my answer as I explore this guide, and then I will have a better picture and clear understanding in this area. You guys are fantastic, patient and very helpful. Again, thanks.

Your First Dialog

| TOC

Connecting Call Legs