Advanced Scripting Techniques

Table of Contents

Advanced Scripting Techniques
Advanced Built-in Variable Types
Contact Management
Session Management
Grammars
Prompts
Advanced Error Handling
Script Interruption
Media
Voice Browser

Advanced Scripting Techniques


This chapter describes advanced variables and techniques you can use when designing custom scripts in the Cisco Customer Response Applications (CRA) Editor.

This chapter contains the following sections:

Advanced Built-in Variable Types

Variables store data while a script executes.

CRA 3.0 includes the following advanced built-in variable types:

Contact

Java Class Name: com.cisco.contact.Contact

A Contact variable consists of a contact representing a telephone call, e-mail message, or HTTP request.

You cannot manually enter a contact as a variable value. Contact variables result only from the Create eMail step (from the eMail palette), the Place Call step (Call Contact palette), and/or the Get Trigger Info step (Contact palette).

You can pass a Contact variable as a parameter to a subflow.

Grammar

Java Class Name: com.cisco.grammar.Recognizable

Grammar variables specify the words or DTMF (Dual Tone Multi-Frequency) tones that the CRA script can recognize.

You can use the following input formats to define Grammar variables:

  • G[], SG[]—Represents an empty grammar, where no value gets recognized.
  • G[AA\grammar], G[grammar, digit], G[grammar.gsl—Represents a user-defined grammar located in the User Grammars directory.
  • SG[grammar], SG[menu\grammar,digit], SG[menu\grammar.gsl], and so forth— Represents a system-defined grammar located in the System Grammars directory.

Note    You can omit the extension, in which case the search attempts all supported extensions (<.gsl> and <.digit>), starting its search with the type of media the call supports. If ASR (Automatic Speech Recognition) is supported, the search starts with <.gsl>; otherwise the search starts with <.digit>.

  • GSL Text Grammar Format (GG[])
    • Supports limited Nuance Grammar Specification Language (GSL).
    • Supports only one expression; no rule set.
    • Must have a slot named <tag> if used as a main grammar in a recognition.
    • Samples:
      GG [(hi {<tag hi>} dtmf-star {<tag bye>} dtmf-4 {<tag 4>} joy {<tag lg>}]]
      GG[[[yes dtmf-1] {tag yes} [no dtmf-2] {tag no}]]
      GG[[dtmf-star {tag cancel} cancel {tag cancel}]]
  • Digit String Grammar Format (DG[])
    • Similar to the Digit File Grammar Format where entries are separated by a "|" character.
    • Each entry is defined as "key=value" or "key" where the keys are defined as "dtmf-x" where "x" is from the set "0123456789*#ABCD", and where values would be the corresponding tag to be returned when the key is pressed or recognized.
    • You can use an optional entry defined as "word=true" to specify that the script should automatically include the word representation of each DTMF digit during a speech recognition.
    • Samples:
      DG[word=true|dtmf-star=bye|dtmf-4=4]
      DG[dtmf-1=yes|dtmf-2=no]
      DG[word=true|dtmf-star=cancel]

Prompt

Java Class Name: com.cisco.prompt.Playable

A Prompt variable contains the information that the script uses to create the prompt or prompts that it plays back to callers. A Prompt variable can be as simple as a single prompt or as complex as a multi-lingual concatenation of multiple prompts.

You can use the following input formats to define Prompt variables:

  • P[] or SP[]—Represents an empty prompt. (No prompt gets played back.)
  • P[AA\AAWelcome], P[AA\AAWelcome.wav], P[App\prompt2], and so forth— Represents user-defined prompts located in the User Prompts directory.
  • SP[dialtone], SP[gen\char\e.wav], and so forth—Represents system-defined prompts located in the System Prompts directory.
  • DP[250], DP[500], and so forth—Represents a delay prompt of the specified number of milliseconds.
  • S[Cisco], and so forth—Represents a prompt in which the specified text will be spelled out according to the rules of the current language of the contact in which the prompt will be played back.
  • N[22.33], N[-2E-23], N[-1], and so forth—Represents a prompt that will be the spoken representation of the specified number; for example, "twenty-two point three three", according to the rules of the current language of the contact in which the prompt is played back.
  • TTS[Cisco Systems]—Represents a prompt in which the script converts the specified text to speech using the system default TTS (Text-To-Speech) provider and the language of the contact in which the prompt will be played back.
  • TTS[any text]—Represents a prompt in which the script converts the specified text to speech. (The text is assumed to be in the same language as the current language of the contact.)
  • #[1], #[22], and so forth—Represents a prompt that will be the spoken representation of the specified ordinal number; for example, "first", "twenty-second", according to the rules of the current language of the contact in which the prompt will be played back.
  • $[12], $[32.50]—Represents a prompt that the script will play back as the specified amount in the system-configured currency in a colloquial format; for example, "twelve dollars", "thirty-two francs and fifty centime", according to the rules of the current language of the contact in which the prompt will be played back.

As in the other advanced variables, the expression input format for the prompt variable is the same as the variable input format:

  • The parameter specified inside the brackets of S[] can also be the result of any string expression; for example S[lastName + firstName].
  • The parameter specified inside the brackets of TTS[] can also be the result of any string or document expression; for example, TTS[companyName], TTS[emailAttachmentDocVariable].
  • The parameter specified inside the brackets of DP[], N[], #[], and $[] can also be the result of any number expression; for example, DP[delay], N[counter + 3], #[position], $[amount + 10.00].

When you use operators with the Expression Editor, if at least one of the operands is a Prompt, then the result will be a Prompt concatenation of the two operands, where the other one is converted to a Prompt according to the following rules:

  • The system converts a String of Character operand to a Prompt using the Spelling Generator (similar to the S[ ] format) or the Character Generator.
  • The system converts a Number operand to a Prompt using the Number Generator (similar to the N[ ] format).
  • The system converts a Time operand to a Prompt using the Time Generator.
  • The system converts a Date operand to a Prompt using the Date Generator.
  • The system converts a Currency operand to a Prompt using the Currency Generator (the spoken representation of the currency code).
  • The system converts a Language operand to a Prompt using the Language Generator (the spoken representation of the language code).
  • A Document operand is assumed to represent an audio stream and is concatenated as is.

Session

Java Class Name: com.cisco.session.Session

A Session variable contains information that can be used to track contacts as they move through the system.

You cannot manually give a Session variable a value. Session variables can only be returned from the Get Contact Info step (Contact palette) and/or the Get Session step (Session palette).

You can pass a Session variable as a parameter to a subflow.

User

Java Class Name: com.cisco.user.User

A User variable contains information that is useful for user authentication.

You cannot manually enter a User variable as a value. User variables can only be returned from the Name To User step of the Media palette.

You can pass a User variable as a parameter to a subflow.

Currency

Java Class Name: com.cisco.util.Currency

A Currency variable represents a specific currency unit that can be used to qualify an amount; for example, when you use the Currency Prompt Generator.

  • Input Format (examples):
    • C[USD]—United States dollars
    • C[EUR]—Euros
    • C[GBP]—British pounds
    • C[COP]—Colombian Pesos
    • C[MXP]—Mexican Pesos

You must define the parameter inside the bracket [] as the upper-case three-letter code defined by ISO 4217.

Language

Java Class Name: java.util.Locale

The Language variable contains information about the language of a contact.

The following input formats are examples of defining Language variables:

L[en_US], L[fr_FR_EURO], L[es_US], L[en_CA_John]

To define the code to be passed inside brackets of L[], you must use one of the following four formats:

  • "<language>"
  • "<language> <country>"
  • "<language>_<variant>"
  • "<language>_<country>_<variant>"

The <language> argument is a valid ISO Language Code. These codes are lowercase two-letter codes as defined by ISO-639.

The <country> argument is a valid ISO Country Code. These codes are uppercase two-letter codes as defined by ISO-3166. If you omit the country code and specify a variant, you must not remove the preceding underscore. This action will result in 2 underscore characters before the start of the variant; for example, L[en__John].

The <variant> argument is a free-form string that the script uses to further qualify the language. You normally use "EURO" to specify the use of the Euro Currency for a European country. You could also use the <variant> argument to distinguish between different talents used for the prompt recordings; for example, L[en__John] vs. L[en_CA_Jenna]. You can compose the variant with many parts, each separated with an underscore; for example, L[de_DE_EURO_Joe].

Java Type

To build more advanced scripts, you can use other Java variable types that are not represented by a built-in type.


Note   You should have experience in Java programming to use Java Type variables and the steps in the JAVA palette of the Cisco CRA Editor.

Use the Variable pane to declare a variable that uses the Java classes in your computer CLASSPATH.

To declare a variable, perform the following procedure.

Procedure

Step 1   In the Variable pane of the CRA Editor window, click the New Variable arrow. (For more information on the Variable pane of the CRA Editor, see the "The Variable Pane" section.)

The Edit Variable dialog box appears.

Step 2   From the Type drop-down menu, choose Java Type.

Step 3   In the Java Type text field, enter a fully qualified class name; for example, "java.util.Vector".

Step 4   Click OK.

The system locates and loads the class from the directories identified by the system CLASSPATH.





Once you successfully declare a variable for a class, you can use it with JAVA palette steps. Use the Create Java Object step to create instances of the class, then use the Execute Java Method to execute methods on this variable.

Contact Management

With Cisco CRA 3.0, the key element in a script is a contact, which represents one form of connection with a remote customer. A contact can be a telephone call, an e-mail message, or an HTTP request.

Scripts use contacts to track connections through the system. The contact is established when the connection is made. The contact lasts until the connection is terminated, as when the script transfers or disconnects a telephone call, responds to an HTTP request, or sends an e-mail message.

You can write scripts to use generic contacts, which are independent of the contact type.

Contacts carry attributes, such as the type.

The script performs actions on contacts through one or more of the following types of channels:

  • CTI (Computer Telephony Interface) port
  • CMT (Cisco Media Termination) dialog channel
  • HTTP control channel
  • ICM (Intelligent Contact Management) channel
  • Nuance dialog channel
  • E-mail control channel
  • ICD (Integrated Contact Distribution) channel

Unlike previous releases of the CRA product, in which steps implicitly referenced call and/or HTTP requests, CRA 3.0 makes it possible for you to assign handles to these contacts and so that the script can act independently on them.

This feature allows you to create subflows that are independent of the way in which the call has originated (without regard, for example, to whether the call originated as an inbound or outbound call).

You can now configure each step that acts on contacts to accept the implicit contact (by choosing the "-- Triggering Contact --" default) or to use a variable that can hold the handle to this contact. With the new Get Trigger Info step of the Contact palette, the script can receive a handle to the implicit contact and save it as a Contact variable that the script can use later in steps or subflows.

You can use the Set Contact Info step of the Contact palette to mark the contact as Handled, which is important for reporting purposes.


Note   If you do not use the Set Contact Info step to mark contacts as Handled, real-time and historical reports may not show that the contact was successfully handled.

Using the functionality of the concept of a contact, you can now design contact-neutral scripts that can contain small logic sections that can be independent of the type of contact.

Because you can now keep a handle to a contact inside the script, it is now possible to design a script that manages more than one of these contacts at the same time. A single script can now be triggered in one way, create outbound calls, and then play prompts on each call individually. This feature offers a new range of possibilities. For an example of a script that handles multiple contacts, see "Working with Multiple Contacts."

CRA 3.0 adds the Contact palette and the Call Contact palette to implement this new "contact-centric" execution mode. The eMail Contact, HTTP Contact, and Media palettes also help implement parts of this feature.

Session Management

The concept of a session provides script designers with an easy way to associate information with a customer (caller) as the call moves through the system (similar to an in-memory database or a shopping cart on the web).

The script automatically associates a call contact with a session object when the contact is received (inbound) or initiated (outbound). You can also create sessions manually, using the Get Session step of the Session palette; this feature may be useful when you want to use sessions for HTTP or e-mail contacts.

Customer information stored in a session object can persist for a specified length of time after the contact ends and be made available to a subsequent contact. This feature can save customers the need to re-enter information such as credit card account digits.

You can store any type of information in these session objects, and retrieve the information with the Set Session Info and Get Session Info steps of the Session palette. You can use special entries for information that will be reported in the associated Contact Call Detailed Record (CCDR). The attribute names for these variables are _ccdrVar1, _ccdrVar2, . . . _ccdrVar5.)


Note   A session is maintained on a single CRA server only; for example, information entered on CRA server #1 will not be available if the call arrives or is transferred to CRA server #2.

Using Mapping Identifiers

The script uses one or more mapping identifiers to identify sessions. These mapping identifiers allow a script to tag a given session with customer-specific information that the script then retrieves on a subsequent call or HTTP request. You can use any kind of information that can be received by the script as a mapping identifier.

For example, suppose a caller places a call and enters information, including an account number that the system uses as a mapping identifier. If the caller places a second call relatively soon after the first call, and re-enters the account number, the script retrieves the earlier session that contains all the previously entered information.

In this case, the script re-assigns the original session object to the call to replace the one that was created when the caller placed the second call.

A session for which a mapping identifier has been added by a script will typically persist in memory for 30 minutes after the contact has ended. You can configure this value in the System Parameters section of the CRA Administration web interface.


Tip If you need to lessen session impact on the memory consumption of the CRA server, lessen the length of time that sessions persist in memory.

Using Session Objects

Session palette steps can be useful in many situations. Some examples:

  • The script connects a call contact to an agent or transfers the call to another agent— Session information can be placed in the CCDRs by using the special _ccdrVar attributes.
  • The script transfers a call contact back to an Interactive Voice Response (IVR) application, or redirects the call contact from one application to another application on the same CRA server—This feature makes information about the original caller available to the script.
  • You want general information to be accessible by multiple scripts independently of contacts or customers—If you create and identify a session with a hard-coded mapping identifier, all scripts can access this session and access or alter information kept there.

Note    The created session, if not associated with a contact, is subject to deletion after the system default session timeout. However, each time the Get Session step retrieves the session, the timeout is reset.

  • You want to access real-time information using the real-time reporting client—This feature lets you see all sessions in the system and their associated values.

For an example that shows the use of Session palette steps, see "Designing IP ICD Scripts."

Grammars

In an IVR script, you use grammars to specify a set of all possible spoken phrases and/or DTMF digits that the system can recognize and act upon during run time.

The CRA Engine uses two types of grammars:

  • System grammars—Used internally by Cisco modules and Cisco sample scripts.

Note    System grammars are provided by Cisco. Cisco makes no guarantees about the continued availability of system grammars in future releases.

  • User grammars—Configured by the user, and manageable by the administrator by means of Windows Explorer. (No web-based API (Application Programming Interface) is available.)

The system retrieves grammars from the Grammar Repository, which you configure from the System Parameters configuration web page of the CRA Administration web interface.

The CRA Editor contains a Grammar palette with the following two steps:

  • Create Language Grammar step—Chooses a set of grammars based on the language context of the call.
  • Create Menu Grammar step—Creates spoken word and/or DTMF menus.

For more information on using these steps, refer to Chapter 10, "Grammar Step Descriptions." in the Cisco Customer Response Applications Editor Step Reference Guide.

Grammar Search Algorithm

The script locates grammars by means of a standard language search algorithm based on the language context of the call.

For example, assuming a language context of {L[fr_FR_Judy], L[en_GB]}, a search will return the first grammar defined for the following directories:

  • ...\fr_FR_Judy
  • ...\fr_FR
  • ...\fr
  • ...\en_GB
  • ...\en
  • ...\default

This type of algorithm allows you to place grammars that are common to all languages in the "default" directory, or grammars that are common to all French languages in the "fr" directory. You can override these common grammars by placing a grammar with the same filename under a different directory, such as "fr_FR".

CRA 3.0 supports the following file extensions:

  • .gsl—for Nuance Grammar Specifications Language format
  • .digit—for digit grammars

If you do not provide an extension, the script locates the grammar file based on the media type of the call when referenced as a user grammar in a CRA script:

  • all supported extensions (.gsl and .digit)
  • the type of media supported by the call; if Nuance ASR is supported, the search starts with .gsl. Otherwise, the search starts with .digit.

File Grammar Formats

CRA 3.0 supports the following two file grammar formats:

The GSL File Grammar Format

The GSL file grammar format (".gsl") supports full Nuance Grammar Specification Language format.

You must define the grammar with a single main rule (prefixed with ".").

You must have a slot named "tag" if you use the grammar as a main grammar in a recognition; for example:

.Main [
hi {<tag hi>}
dtmf-star {<tag bye>}
dtmf-4 {<tag 4>}
joy {<tag lg>}
]

The Digit File Grammar Format

The Digit file grammar format (".digit") is based on Java Properties File, in which a key is defined as "dtmf-x", where "x" is from the set "0123456789*#ABCD" and its value is the corresponding tag to be returned when a key is pressed or recognized.

You can use an optional entry defined as "word=true" to specify that the word representation of each DTMF digit should be automatically included during a recognition; for example:

word=true
dtmf-star=bye
dtmf-4=4

Automatic Conversion

The script uses grammars independently from the following types of supported media:

  • Cisco Media Termination (CMT)—DTMF digits
  • Automatic Speech Recognition (ASR)—Speech

The script automatically converts grammars from one type to the other, based on the media type of the call.

If the call uses a CMT Dialog channel and you have specified a GSL grammar, the script automatically analyzes the grammar and extracts all defined digits to create a corresponding digit grammar.

If the call uses an ASR Dialog channel and you have specified a digit grammar, the script automatically converts the grammar to a corresponding GSL grammar. If the grammar is marked with "word=true", the script includes the spoken representation of the digit, in the current language of the call, in the GSL grammar.

Passing Grammars to Steps

You can pass grammars to the following steps in a script:

  • Simple Recognition step—Use the Simple Recognition step customizer window to specify all tags in the grammar.
  • Explicit Confirmation step—Use the Explicit Confirmation step customizer window to associate the tags with the value "yes" to represent a successful confirmation, or "no" for a negative confirmation.

  • Note   Tags for grammars are case-sensitive.

Prompts

The CRA Editor uses the following two kinds of prompts:

  • System prompts—Used internally by Cisco modules and Cisco sample scripts.

Note    System prompts are used internally by the system. Cisco makes no guarantees about the continued availability of any system prompt in future releases.

  • User prompts—Defined by the user, and manageable by the administrator by means of the Prompt Management configuration web page of the CRA Administration web interface.

All Media and Prompt steps support prompts specified in the following three ways:

  • String expression—User-defined prompts located in the User Prompts directory of the CRA Administration web interface.
  • Document expression—Recorded audio streams.

Document objects are returned by the Recording step (Media palette), Get User Info step (User palette), DB Get step (Database palette), and the Create File Document step and Create URL Document steps of the Document palette.

  • Prompt expression—Dynamically created at run time.

Note    You must define all prompts played back and recorded with a RIFF header of type WAVE and G711 u-law format.

The script retrieves both user and system prompts from the Prompt Repository. You can manage these prompts from the Prompt Management Configuration web page of the CRA Administration web interface. (For more information on configuring the Prompt Management Configuration web page, refer to the Cisco Customer Response Applications Administrator Guide.)

Creating Prompts

You can use the steps in the Prompt palette of the CRA Editor to create the following prompts:

  • Conditional Prompt—Creates one of two specified prompts, based on the result of evaluating a specified Boolean expression
  • Container Prompt—Creates one of the three prompts:
    • Concatenated Prompt—Creates a prompt that combines multiple prompt phrases into one prompt.
    • Escalating Prompt—Creates a prompt that plays back one prompt phrase at a time, starting with the first in a series and moving to the next one on each retry within a Media step.
    • Random Prompt—Creates a prompt that plays back one phrase from the supplied list in a random order.
  • Generated Prompt—Generates a prompt using generators that act on variables (currency, date, digit, string, and time).
  • Language Prompt—Selects a prompt from the set of prompts specified based on the language context of the call at run time.
  • TTS Prompt—Creates a prompt based on the text from a string expression or a document expression to be played back as speech, using the system default TTS provider.

  • Note   For scripts running with ASR, you cannot use multiple Play Prompt steps to concatenate prompts together if you expect the prompts to be interrupted by speech (that is, when barge-in is enabled), because speech cannot be buffered (like DTMF) on the first step and then used on the last step for recognition. You must prepare a grammar to be ready to perform the recognition if the prompts are interrupted by a caller barge-in.

Prompt Search Algorithm

Similar to the way it handles grammars, the script locates prompts by means of a standard language search algorithm based on the language context of the call.

For example, assuming a language context of {L[fr_FR_Judy], L[en_GB]}, a search returns the first prompt defined for the following directories:

  • ...\fr_FR_Judy
  • ...\fr_FR
  • ...\fr
  • ...\en_GB
  • ...\en
  • ...\default

Note    If no extension is provided, <.wav> is assumed.

This type of algorithm allows you to place prompts that are common to all languages in the "default" directory, or place prompts that are common to all French languages in the "fr" directory. You can override these common prompts by placing a prompt with the same filename under a different directory, such as "fr_FR".

Advanced Error Handling

The CRA Editor allows you to provide scripts with two advanced ways to handle errors.

The following sections describe these two advanced error handling techniques:

Using the On Exception Goto Step

The On Exception Goto step of the General palette of the CRA Editor sends the execution to a specified place in the script when an exception is generated, which allows you to provide logic in the script for handling exceptions.

By using the On Exception Goto step for a specific exception in a script, you can register a new handler for a given exception or override a previously existing one.

The registration process is for the complete script, so it does not matter where the exception occurs (before, during, or after the given step). Once the step executes, the handler is registered until either a new one is re-registered or the exception is cleared with the On Exception Clear step of the General palette.

If an exception results in a subflow, the script first consults the exception handlers of the subflows. If none are defined for the given exception, the exception aborts the subflow and the CRA Engine looks for exception handlers in the parent script and so on until either an exception handler is found or the script aborts completely.

If no exception handlers are registered, the script aborts and error handling falls back to the last level of error handling, which is the default script.

Using Default Scripts

The default script is the last level of user-defined error handling before the system kicks in and applies a default system treatment to all active contacts.

You can also configure a separate, default script when you provision a Cisco script application. The system invokes this default script under the following conditions:

  • When the main script aborts, either because of an uncaught exception or because the CRA server is unable to invoke the primary script because it has not been properly validated.
  • When an incoming call must be aborted because the CRA server has reached its limit for the number of simultaneous sessions for the application.
  • When the CRA Engine is currently out of available tasks to run the script for an incoming call.

In each of these scenarios, the script marks all active contacts as aborting before the default script is executed. The final state of these contacts will be ABORTED even if they are transferred or redirected as a result of the execution of the default script.


Note   Remember that the purpose of the default script is to gracefully terminate the call when the main script fails, not to have a fall back to provide the original services intended by the primary script. This distinction is important because using system resources to execute this default script may impair system performance. If the primary script fails too often, then you should fix the primary script rather than providing another script to attempt the same task.

The default script performs the following tasks:

  • Redirects the call to an operator or to another extension for further processing
  • Provides a customized error message to an HTTP request
  • Plays back a graceful excuse to the caller for the system problems before hanging up

You can transfer the state of the primary script to the default script before the primary script starts. To do this, define variables in the default script with exactly the same name and type as the variables in the main script. The variables in the default script are then automatically populated with the last values that were held by the corresponding variables in the primary script.

By doing so, you may, for example, be able to tell how many calls were active and terminate all of them gracefully, or you may be able to gain access to information about the caller and use it in your customized message.

Just as in the primary script, you can configure the default script at provisioning time by defining variables as parameters.

For ICM scripts, the default script executes if the ICM script issues a request for connecting to the default treatment. The default script, however, can execute only once, so if it has already executed because of an ICM connect request to a default treatment, it will not be re-executed if the default script fails.

The default script does not execute if the primary script ends normally, even if contacts are still active. In this case, it is considered to be a design problem for the primary script. In such a case, all active contacts not marked as handled abort, and all active contacts marked as handled are simply terminated.


Note   Remember that the default script provides only a final feedback to the contact regarding the system problem and does not continue the service or restart the service. You should therefore make the default script short and to the point.

The default treatments that the system applies if the contact is still active after the system executes the default script (if any) are:

  • CallContact—Plays back the prompt, "We are currently experiencing system problems, please call back later" as an announcement, followed by a fast busy signal.
  • HTTP Contact—Returns an INTERNAL SERVER ERROR (code 500).
  • eMail Contact—There is no system default treatment for an e-mail contact.

Script Interruption

Script interruption is a feature that allows external events to interrupt the current processing of a script in order to return to another part of the script or stop the execution of the script.

Script interruption is typically used in the following situations:

  • The script plays in an Automatic Call Distribution (ACD) environment in which it provides features such as service-on-hold or music-on-hold to a caller waiting in a queue for the system to transfer the call to an available agent.
  • The script needs to be notified that one of its contacts has been remotely terminated, as when, for example, the caller hangs up.
  • You are using the CRA Editor to debug a script and the CRA Editor makes a request to end the debugging session in the middle of that script.

  • Note   In every case, any event that triggers the need to interrupt the script can occur at any time while the script executes other steps. In previous CRA releases, script interruption could happen only for some of these events and only in some of the steps.

By default, scripts are automatically interruptible before any step is executed. Should any external event (such as those described above) interrupt the script, it will continue processing based on the proper handling for the particular event before it begins to execute the next step.

If you want two consecutive steps to execute without the possibility of interruption, you must move these two steps to a subflow where you can disable interruptions completely while the script processes that subflow.

CRA 3.0 introduces a new "interruptible" option for some steps that allows you to indicate whether or not the script can interrupt the step from within when an external event occurs.


Note   For Media steps, CRA 3.0 has renamed the old "interruptible" option that allowed a caller to stop the playback of the prompts using either DTMF or voice (in case of ASR calls). The new name is "barge-in".

The following paragraphs describe in more detail the external events that can cause interruptions and the default processing associated with them:

  • A contact is remotely terminated.

When a caller hangs up, the script will be interrupted (if possible) and a ContactInactiveException will be generated. This exception can then be caught with the OnExceptionGoto step of the General palette and properly handled.

If a caller hangs up and you have not provided any exception handling logic, the script immediately aborts.

When managing multiple contacts, the OnExceptionGoto step cannot differentiate which contact was remotely terminated. Instead, it must specify a Label to which it can loop through all known contact variables and use the Get Contact Info step of the General palette to search for an Active flag; or save the exception into a variable and use the Execute Java Method step of the JAVA palette and the getContact() method to extract the Contact object that became inactive.

  • A debugging session is terminated.

When you click the End button on the toolbar of the CRA Editor, the script is interrupted and aborts without the possibility of catching or handling this case.

  • An ICD agent becomes available.

This event occurs only if the script has previously executed a Select Resource step from the ICD palette. When an agent becomes available, the script is interrupted and control is returned to the Select Resource step, exiting through either the Selected or Connected branches depending on the configuration.

  • An ICM agent becomes available.

The script is automatically interrupted without the possibility of catching or handling this case.

If an interrupting event happens when the script is not currently interruptible, the script is automatically interrupted whenever it becomes interruptible again. For example, although a script is not interruptible when it is running a subflow marked to disable interruptions, it will process the interruption as soon as the subflow terminates and control is returned to the parent (if that primary script is interruptible).

As another example, although a script is not interruptible while waiting for the results of a database fetch, it will process the interruption as soon as the results return and before the script executes the next step (unless the interruptible option has been disabled).


Note   The Interrupt option in CRA 2.x customizer windows has been renamed "barge-in."

Figure 2-1 shows the Disable Interruptions option in the General tab of the Call Subflow customizer window.


Figure 2-1   Disable Interruptions Option—Call Subflow Step (General Tab)


Refer to the Cisco Customer Response Applications Editor Step Reference Guide for the script interruptible options for specific steps.

Media

In previous releases of CRA Editor, media was automatically associated with every single CTI port configured, and only simple media termination was available: the system could play prompts or get DTMF digits.

With CRA Editor 3.0, you can configure the type of media that you want to associate with each trigger.

The following three media types are available:

  • Cisco Media Termination (CMT)
  • Nuance Automatic Speech Recognition (ASR)
  • None (for calls without media)

All calls you configure to use media are counted toward the number of licensed IVR ports.

All calls you configure to use ASR are counted toward the number of licensed ASR ports.

In order to allow for better provisioning, you can configure more CTI ports than the number of licensed IVR ports and more ASR channels than the number of licensed ASR ports.

At run time, the system will automatically reject a call received that requires media if accepting it would exceed the number of licensed IVR ports.

The system will also automatically reject a call that requires ASR if accepting it would exceed the number of licensed ASR ports. In this case, the system will not fall back to the secondary dialog group if an ASR channel was available in the primary dialog group.

Media-Less Calls

You use a media-less call when you expect no media interactions with the caller (interactions such as prompting, getting DTMF digits, or speech recognition).

Examples of applications that require no media are e.911 redirect and simple queuing.


Note   You can generate Music on Hold to a caller for a media-less call, because this function is not controlled by the CRA Engine. This type of call uses fewer CPU resources on the CRA server than other types of calls, which may allow you to increase the capacity of the CRA Engine.

Media Neutrality

All Media palette steps of the CRA Editor are designed to work on both types of media (DTMF and ASR), with the exception of the Voice Browser step, which can work only with ASR.

You can query the Get Contact Info step of the Contact palette to check if ASR is supported for a given call, and you can create conditional prompts to play different prompts (if required) based on the result of the query.

The system automatically converts grammars from one format to the other based on the current media type of a call.


Note   For scripts running with ASR, you cannot use multiple Play Prompt steps to concatenate prompts together if you expect the prompts to be interrupted by speech (that is, when barge-in is enabled), because speech cannot be buffered (like DTMF) on the first step and then used on the last step for recognition. You must prepare a grammar to be ready to perform the recognition if the prompts are interrupted by a caller barge-in.

Media Steps

The following sections describe some of the steps that take advantage of the media capabilities of the CRA 3.0 Editor.

Name To User Step

The Name To User step is a modified version of the Name To Address step in previous releases.

The step now returns a User object that you can later query with the Get User Info step to retrieve the user's extension, e-mail address, and spoken name.

If you request the operator option, the Name To User step returns control through a new Operator output branch.

The system can match only user names that are defined with characters from the English alphabet (unless the step is used with an ASR channel).

Recording Step

The Recording step allows you to record an audio segment from the caller and return it as a Document object that can, for example, be uploaded as a spoken name, saved to disk or to a database, or e-mailed.

The system defines all recordings as Document objects with a RIFF header of type WAVE and encoded using G711 u-law format.

Explicit Confirmation Step

The Explicit Confirmation step provides a simple building block for confirming a question, and is a limited version of a Menu or Simple Recognition step.

You define the Explicit Confirmation step with a default grammar that accepts the following input:

  • CMT—1 for yes and 2 for no
  • ASR—typical yes/no grammar in proper language

You can also override the default grammar with a user-defined grammar.

See Grammars of "Advanced Scripting Techniques," for more information on defining and using grammars.

Implicit Confirmation Step

You typically use the Implicit Confirmation step in speech-enabled applications in order to provide the caller with a way to confirm an action without having to ask a question.

The script plays back a prompt explaining the action to be taken and then waits a configured number of seconds for any input from the caller.

If the caller presses any DTMF digits or speaks before the end of the prompt or the configured timeout, the confirmation is considered to have failed.

An implicit confirmation executed over a CMT dialog channel will ignore speech; only DTMF digits pressed by the caller will fail the confirmation.

Simple Recognition Step

The Simple Recognition step is an extension to the original Menu step that allows the designer to pass any user-defined grammar to be used for matching user input.

The Simple Recognition step works over CMT. Only DTMF digits can be matched against the specified grammar.

Voice Browser

The Voice Browser feature allows you to design voice-enabled applications using standard VoiceXML (Voice eXtensible Markup Language) language. Voice Browser currently supports VoiceXML 1.0, as well as a subset of new VoiceXML 2.0 elements.

This section includes the following topics:

For more information on developing voice-enabled applications, see "Developing VoiceXML Applications." For more information on using the Voice Browser step in the CRA Editor, refer to the Cisco Customer Response Applications Step Reference Guide.

Understanding VoiceXML

Voice eXtensible Markup Language (VoiceXML) is designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed-initiative conversations.

The main goal of VoiceXML is to bring the full power of web development and content delivery to voice response applications, and to free the authors of such applications from low-level programming and resource management. VoiceXML enables integration of voice services with data services that use the familiar client-server paradigm. A voice service is viewed as a sequence of interaction dialogs between a user and an implementation platform.

Document servers, which may be external to the implementation platform, provide the dialogs. Document servers maintain overall service logic, perform database and legacy system operations, and produce dialogs. A VoiceXML document specifies each interaction dialog to be conducted by a VoiceXML interpreter. User input affects dialog interpretation and is collected into requests submitted to a document server. The document server may reply with another VoiceXML document to continue the user session with other dialogs.

VoiceXML is a markup language that performs the following tasks:

  • Minimizes client/server interactions by specifying multiple interactions per document
  • Shields application authors from low-level and platform-specific details
  • Separates user interaction code (in VoiceXML) from service logic (CGI scripts)
  • Promotes service portability across implementation platforms; VoiceXML is a common language for content providers, tool providers, and platform providers
  • Provides an easy programming language to use for simple interactions, and yet provides language features to support complex dialogs

The VoiceXML language describes the human-machine interaction provided by voice response systems, which include the following:

  • Output of synthesized speech (Text-To-Speech, or TTS)
  • Output of audio files
  • Recognition of spoken input
  • Recognition of DTMF input
  • Recording of spoken input
  • Provision of telephony features such as call transfer and disconnect

VoiceXML provides the means for collecting character and/or spoken input, for assigning the input to document-defined request variables, and for making decisions that affect the interpretation of documents written in the language. You can use URLs to hyperlink a document to other documents.

Voice Browser Architecture

Voice Browser consists of the following three components:

  • Document server—Processes requests from the VoiceXML interpreter. The server produces VoiceXML documents in reply.
  • VoiceXML Interpreter—Processes the document. The VoiceXML interpreter executes the VoiceXML application, doing prompting and voice recognition via the CRA Engine. The VoiceXML interpreter processes the input and may then branch or submit information to the document server according to the application logic.

The Voice Browser interprets VoiceXML documents and performs the dialog with the user. The web application model is a client server model. The role of the Voice Browser is that of a web client, fetching documents from a web server.

  • Implementation Platform—Detects and answers incoming calls and responds to other telephony events. It is also responsible for prompting and receiving user input. The VoiceXML interpreter controls the CRA implementation platform.

Figure 2-2 shows the architecture for the Voice Browser system.


Figure 2-2   Voice Browser Architecture


The following is an example of a process flow:

1. The user makes a call to a phone number.

2. The CRA system answers the call and invokes the VoiceXML interpreter to perform the dialog.

3. The VoiceXML interpreter makes a request "http://abc/HelpDesk.vxml".

4. The document server receives the request. It processes, formats, and returns the document.

5. The VoiceXML interpreter interprets the document.

6. The interpreter performs prompting and voice recognition through the CRA Engine.

7. Based on user input, the application continues. For example, it may loop back to Step 3 to make another request with information gathered to the document server.

Voice Browser Development Tools

You can use Voice XML and the following tools to develop voice applications:

  • Voice Browser
  • Web application server
  • VoiceXML development tool (optional)

The Voice Browser interprets the VoiceXML documents and executes dialogs with the user. The role of the Voice Browser is as a web client, fetching documents from a web server.

For information on configuring VoiceXML applications using the Voice Browser, refer to the Cisco Customer Response Applications Administrator Guide.

For information on the Cisco implementation of VoiceXML, see "VoiceXML Implementation for Cisco Voice Browser."

You can use any web application server for deploying VoiceXML applications that use Voice Browser. In addition to acting as a document repository and server, the web application server often supports server-side scripts for generating dynamic documents. Some examples are J2EE (Java 2 Platform Enterprise Edition) technologies such as servlets and JSP (Java Server Pages), .NET technologies, and Perl scripts. The web application server often provides backend integration, security and XML/XSLT presentation support.

Users already running a web server for HTML-based applications can leverage the existing infrastructure to serve voice applications. This functionality also means you can use a single model for developing HTML and voice applications.


Note   You can also use the file system or anonymous FTP server as the document server. In this case you can deploy only static VoiceXML documents. This functionality is useful for running simple applications with minimal setup and system requirements.

The Voice Browser does not require or provide any VoiceXML editor or IDE (Integrated Development Environment). Since VoiceXML is a text-based XML document, you can use numerous authoring tools, including simple text editors, server scripting languages, and third-party VoiceXML editors.