CCXML in Action: A CCXML Auto Attendant

Transcription

1 CCXML in Action: A CCXML Auto Attendant CCXML is the right platform on which to build applications that span the gap between self-service and traditional telephony call control. by Steve Apiki CCXML (Call Control XML) is the bridge between stand-alone IVR applications and call processing systems. Using CCXML, developers can build applications that combine self service features, such as voice dialogs, and call control features, such as More Resources Part 1 of this Series Auto Attendant Sample Application Product Brief: Avaya Dialog Designer Product Brief: Avaya Voice Portal More DevConnect Resources conferencing, and build these applications on a single, integrated platform. In the first part of this two-part series, we looked at the structure of CCXML, at its language elements, and described some of its capabilities. In this article, we'll walk through a full CCXML program and get a feel for building applications that combine CCXML and VXML (Voice XML) using Avaya Dialog Designer. Avaya Dialog Designer is an Eclipse-based IDE for building and testing CCXML and VXML applications. Dialog Designer supports speech application development with graphical design tools, application templates, and an embedded voice browser for testing and debugging applications. We'll focus our discussion of practical CCXML on the Auto Attendant sample application for Dialog Designer (the sample application is available from the DevConnect website with free registration). Using Auto Attendant as a guide, we'll see where CCXML fits in the development environment, how a real application is structured, and dive into the CCXML behind the Auto Attendant's call control features. One Service, Two Applications Auto Attendant directs callers to the appropriate extension and allows the called party to accept or reject the incoming call. It's actually composed of two applications, AutoAttendantCC, the CCXML application that drives the call, and AutoAttendantDialog, a VXML application that facilitates user interaction. This is typical of how you might structure a combined speech and call control project. Figure 1 shows the two projects together in Dialog Designer.

2 Figure 1. The Auto Attendant sample application is composed of a CCXML project and a VXML project. We won't spend much time on the VXML side here, other than to describe how the CCXML and VXML programs interact. Both AutoAttendantCC and AutoAttendantDialog run on a web server, each at its own URL. To start up a dialog, AutoAttendantCC specifies the AutoAttendantDialog URL as its source, and the voice browser loads the VXML document from the web server. The voice browser starts up a VXML interpreter instance to run the dialog and hands values from the CCXML session to the new VXML session. AutoAttendantCC, the CCXML application, is essentially a single JSP (JavaServer Page) that generates the CCXML document to be handed off to the web browser. Although it's written as a JSP, JSP scripting is used sparingly, for the most part to dynamically generate URLs otherwise it's a static CCXML document. All of the action in AutoAttendantCC takes place in the CCXML interpreter where the voice browser processes the document. State by State As we noted in part one of this series, a CCXML application consists of a series of event handlers and can be modeled as a finite state machine. Figure 2 shows a simplified state diagram for Auto Attendant. It's simplified because it includes only transitions that help to illustrate the primary call flow. There are a number of additional transitions (for example, if the caller hangs up unexpectedly) that are not shown.

3 Figure 2. The state diagram for Auto Attendant. The application begins in the incomingcall state. Each transition in the diagram represents a CCXML event handler that responds to the incoming event in some way, sometimes by changing the current state. The application proceeds from state to state until the session terminates at the exit state. These are the possible states in Auto Attendant: incomingcall The starting state, where the application accepts incoming calls. initialdialog After making a connection, Auto Attendant starts the initial VXML dialog to ask the caller for the extension to call. This dialog also asks the caller to record his or her information so that it can be presented to the callee when the call is transferred. in_initialdialog For each of the three VXML dialogs, the corresponding in_-state occurs while the VXML interpreter is running the dialog. It's primarily a place to handle dialog.exit events.

4 placecall Auto Attendant creates the outgoing call to the callee's extension. If the connection fails, Auto Attendant sends itself a start.callnextextn event which causes the transition to getextndialog. callerinfodialog The caller info dialog presents the called party with the recorded information from the caller. The callee can accept or reject the call. in_callerinfodialog If the callee rejects the call, Auto Attendant sends itself a start.callnextextn event which moves the state back to getextndialog. If the call is accepted, Auto Attendant bridges the two call legs and moves to the connected state. connected The two call legs are bridged. If the call is disconnected in this state, the session terminates. getextndialog This dialog asks the caller for a new extension to dial. Auto Attendant starts this dialog on any outbound call failure or if the callee rejects the call. in_getextndialog Occurs while the get extension dialog is active. If the caller specifies a new extension, Auto Attendant moves back to placecall to place another call. Accepting the Call All CCXML documents consist of an <eventprocessor> element that contains a number of transitions (event handlers). In Auto Attendant, the first transition accepts any incoming calls and looks like this (Author's note: in this and all following CCXML fragments, we've removed some logging calls from the Avaya sample application to make things clearer): <transition event="connection.alerting" state="incomingcall"> <assign name="in_connectionid" expr="event$.connectionid" /> <accept connectionid="in_connectionid" /> This transition responds to connection.alerting events in the incomingcall state (the initial state) only. It responds by assigning the connectionid from the event to a global variable (in_connectionid) that can be seen from any transition. Finally, it accepts the call with the CCXML <accept> element. Unless there are errors, calling accept should result in a connection.connected event in the same state. What we want to do at this point is to launch the initial VXML dialog, but instead of doing so directly (with <dialogstart>), we move to a central dispatcher transition that handles the starting up of all dialogs: <transition event="connection.connected" state="incomingcall"> <assign name="state" expr="'initialdialog'" /> <assign name="dialogaction" expr="'initial'" /> <assign name="using_connectionid" expr="in_connectionid" /> <send targettype="'ccxml'" name="'start.dialog'" target="session.id" delay="'0s'" /> This transition uses something we haven't discussed before, an application-specific event. After logging the event information, Auto Attendant sets the dialogaction and using_connectionid global variables and calls the <send> element to send an event named "start.dialog" to itself

5 (session.id refers to the current CCXML session). Although events can include fields, this event doesn't; instead, the global variables are used to communicate with the transition that handles the event. Dialog Interactions Here is the transition that handles start.dialog: <transition event="start.dialog" state="initialdialog getextndialog callerinfodialog"> <dialogprepare connectionid="using_connectionid" type="'application/voicexml+xml'" src="'<%=locationext%>/autoattendantdialog/start'" namelist="dialogaction inputdata" parameters="dialogaction inputdata" /> As discussed earlier, this is a dispatching event handler that centralizes the startup of all dialogs. The event processor selects this transition for the start.dialog event in any one of the three states (initialdialog, getextndialog, or callerinfodialog) where the event can be sent. Auto Attendant uses the <dialogprepare> element to prepare dialogs before actually starting them with <dialogstart>. dialogprepare gives the CCXML interpreter the opportunity to fetch any resources it needs for the dialog prior to startup. dialogprepare may be called ahead of time when it will be less noticeable to the caller (for example, in response to the connection.alerting event before accepting the call) if the dialog takes a long time to set up. In dialogprepare, we specify the parameters to pass to the VXML dialog as a list of variable names in the parameters attribute. These are the same global variables that we set up before sending start.dialog. The VXML interpreter will have access to these values as session variables in the VXML session. Once the dialog is prepared (in a common dialog.prepared event handler), we use <dialogstart> to run the prepared dialog. We then wait for dialog.started as a signal to move to the next state. For the initialdialog state, the next state is in_initialdialog. Each state that starts a dialog has a corresponding "in_" state where the dialog is active and the CCXML application is ready to handle the dialog.exit event. Each dialog.exit handler unpacks the values obtained from the caller by the VXML dialog. Here is the dialog.exit handler for in_initialdialog: <transition event="dialog.exit" state="in_initialdialog"> <assign name="recording" expr="event$.values.outputdata" /> <assign name="inputdata" expr="recording" /> <assign name="dialogresult" expr="event$.values.dialogresult" /> <assign name="extntocall" expr="event$.values.extensiontocall" /> session.connections[event$.connectionid].remote" /> <if cond="dialogresult == 'CANCEL'"> <log expr="'user quit application exiting'" /> <disconnect connectionid="in_connectionid" /> <exit /> </if> <assign name="state" expr="'placecall'" />

6 <createcall dest="extntocall" connectionid="out_connectionid" timeout="10000" callerid="session.connections[event$.connectionid].remote" /> The dialog.exit event object includes a values associative array. We can read the dialog's output values from this array by name. For example, we read the extension specified by the caller from event$.values.extensiontocall and store this in a global variable. If the caller cancels from the initial VXML dialog, we read the "CANCEL" value back from event$.values.dialogresult and terminate the session. Otherwise, we proceed to the placecall state to start the outbound call. Placing the Outbound Call As shown above, we place the outbound call using <createcall>, specifying the extension to call as an attribute. We also relay an identifying string for the incoming call to the called extension using the callerid attribute. If createcall fails (for example, because the extension was invalid) we'll receive a connection.failed event. In the connection.failed transition, we use another application-specific event ("start.callnextextn," as shown in the state diagram) to move to the getnextextn state, where we'll prepare and start a dialog to ask the caller for another extension. If createcall succeeds, we want to play the recorded information from the caller to the called party and let him or her decide to accept or reject the call. We do that using the start.dialog event to get back to the dialog dispatcher, specifying the playcallerinfo dialog and that the dialog should be connected to the outbound call leg: <transition event="connection.connected" state="placecall"> <assign name="state" expr="'callerinfodialog'" /> <assign name="dialogaction" expr="'playcallerinfo'" /> <assign name="inputdata" expr="recording" /> <assign name="using_connectionid" expr="out_connectionid" /> <send targettype="'ccxml'" name="'start.dialog'" target="session.id" delay="'0s'" /> When this dialog exits, we know whether the callee accepts or rejects the call, and can act accordingly. This is the relevant part of the dialog.exit handler for in_callerinfodialog: <if cond="calledpartyresponse == 'yes'"> <assign name="state" expr="'connected'" /> <join id1="in_connectionid" id2="out_connectionid" duplex="'full'" /> <elseif cond="calledpartyresponse == 'no'" /> <disconnect connectionid="out_connectionid" /> </if> If the callee accepts the call, we bridge the two call legs using the <join> element and move to the connected state. If not, we disconnect the outbound connection (only) using <disconnect>. When we receive the corresponding connection.disconnected event, we send

7 the start.callnextextn event to get us back to the getnextextn state, where again we'll ask the caller for a new extension to try. The Right Platform Auto Attendant includes both examples of common CCXML tasks, like sending and receiving values to and from voice dialogs, and some more advanced techniques, like using applicationspecific events to centralize event handling. That makes it a good sample application on which to hang a discussion of practical CCXML, as we've done here. It's also an example of the kinds of powerful applications you can build by combining VXML dialogs with the call control capabilities of CCXML. Auto Attendant is a self-service application that would be impossible to build in VXML alone. CCXML extends the web platform beyond its role as an isolated host for IVR applications, where telephony functions beyond a simple transfer would need to be programmed elsewhere, and by other developers. Instead, CCXML makes the web the right platform for building innovative new self-service applications with the ability to connect callers with a variety of services and applications, as well as with other people. Steve Apiki is senior developer at Appropriate Solutions, Inc., a Peterborough, NH consulting firm that builds server-based software solutions for a wide variety of platforms using an equally wide variety of tools. Steve has been writing about software and technology for over 15 years.