ASAI application design

The ASAI feature provides four IVR Designer external functions that can be used to access ASAI capabilities. The following table describes the ASAI external functions.

ASAI voice application design

ASAI voice response applications are designed using the A_Callinfo and A_Tran external functions within voice response applications. Other standard IVR Designer nodes are also used in the voice application to answer the call, greet the caller, collect data, and so on.

The A_Callinfo and A_Tran external functions are used only in applications that handle calls delivered to an Avaya IR system telephony channel. These two external functions are not used in routing and monitoring applications where, in contrast to voice applications, a call is not present at a telephony channel.

For ASAI voice response applications, incoming calls are routed to the Avaya IR system over telephony channels configured either as extensions in an ACD split or as agent ID's under a VDN in an EAS environment on the DEFINITY G3 switch. The Avaya IR system uses the Notification capability of ASAI to monitor the ACD split or VDN. As a call is offered, the Avaya IR system receives event reports indicating the status of the call, for example, call offered, queued, alerting, and connected event reports. The Avaya IR system uses the information contained in these event reports to provide the following capabilities:

• DNIS and ANI service – The DNIS or ANI information associated with the incoming call is used to select a particular IVR Designer application to service the call. A unique dialed number can be provided for each unique voice response application. Each dialed number is typically represented by a unique VDN on the DEFINITY G3 switch. Calls to these different VDNs can be routed to the same Avaya IR system. The DNIS and/or ANI information associated with an incoming call is then used to select a particular application. An administrative screen on the Avaya IR system allows the different dialed numbers to be associated with a specific voice response application. This allows telephony channels to be shared across many applications. Prior to this capability, channels had to be dedicated to specific IVR Designer applications.
• Call information – Once the Avaya IR system answers the call, the ASAI information related to the call can be retrieved for use in the voice application that is handling the call. In particular, the A_Callinfo external function can be used to obtain ANI, DNIS, switch-collected user data (touch-tone digits), call ID, Universal Call Identification (UCID), User-to-User Information (UUI), ANI II digits, network (ISDN) Redirecting Number, and incoming trunk group ID if ANI is not available.

A user designing a voice application need not be concerned with processing the individual, lower-level ASAI event reports for incoming calls to the Avaya IR system. Rather, special software is provided as part of the ASAI feature. This software processes the event reports and stores the information contained in these reports on a per-call basis. The DNIS or ANI information associated with a call is used to start a specific voice application on the channel that receives the call. The A_Callinfo external function can then be used within the application to retrieve this information and use it in subsequent IVR Designer nodes.

A subset of the Third Party Call Control capability of ASAI is also supported for ASAI voice response applications. In particular, the A_Tran external function uses Third Party Call Control to transfer a call away from the telephony channel.

The use of the A_Tran external function within a voice response application invokes the Third Party Call Control operations of third-party take control, third-party hold, third-party make call, and third-party merge. This sequence of ASAI operations invoked with A_Tran effects a transfer of the incoming call to the destination specified with the Destination Number field in A_Tran. Hence, the application designer is not required to program many individual ASAI operations. The use of a single external function effects the transfer.

Standard switch-hook-flash transfers are still possible when the ASAI feature is used. The use of A_Tran, however, provides three significant enhancements over existing transfer mechanisms:

• Transfers are faster, quieter from the caller's perspective, and more reliable since third-party call control is used rather than the standard switch-hook-flash mechanism.
• The transfer can be completed using direct agent calling. This is done by setting the Destination Number field in A_Tran to the desired agent extension and by setting the Split Extension field to the ACD split logged into by the agent. Direct agent calling allows the transfer to be completed to a specific agent while maintaining accurate ACD split measurements. The DEFINITY G3 switch direct agent calling feature can only be invoked via ASAI.
• Information captured in the voice application can be saved for subsequent use in a data screen delivery application. Information assigned to the Avaya IR system Data field of A_Tran is saved by the Avaya IR system even after the voice application terminates. The Avaya IR system associates this data with the transferred call and makes this data available in call events passed to the monitoring application that monitors the transferred call.

The third enhancement is very useful for data screen delivery applications where the screens delivered to agents are based on data collected by the Avaya IR system. Since data collected in a voice application can be saved and is included in call events that are made available to the monitoring application, the host application is simplified. For instance, a CONNECT event (described later) that is made available to the monitoring application contains both the extension of the agent receiving the transferred call and the Avaya IR system data that was saved from the voice application that previously serviced the caller. This single event is then passed to the host, thereby providing all information needed by the host application in a single message.

Routing application design

Routing applications make use of the routing capability supported by ASAI and the call-vectoring feature on the DEFINITY G3 switch. In routing scenarios, calls are not physically delivered to telephony channels on the Avaya IR system. Instead, incoming calls to the DEFINITY G3 switch are directed to a vector containing an adjunct route step. The adjunct route step causes a route request message to be sent to the Avaya IR system. The route request message contains information pertaining to the call, for example, ANI or network (ISDN) redirecting number. The Avaya IR system uses this information to determine where to route the call.

After the Avaya IR system determines where to route the call, a route select message is sent back to the DEFINITY G3 switch. The route select message contains a destination address provided by the Avaya IR system that the DEFINITY G3 switch uses to further direct the call. In routing scenarios, the Avaya IR system can be viewed as a routing server which the DEFINITY G3 switch calls upon to route calls processed with a routing vector.

Note that as a result of routing, the call might be directed to an Avaya IR system to collect more information from the caller. This would be the case, for example, if the information contained in the route request is not sufficient to identify the caller, for example, ANI not recognized.

Routing applications on the Avaya IR system are supported through the use of routing applications that are designed using the A_Event and A_RouteSel external functions. The A_Event external function is used to bring information contained in a route-request message that is sent by the DEFINITY G3 switch up to the application level. The A_Event external function returns a ROUTE REQUEST event when the DEFINITY G3 switch sends such a message. If no route-request messages are sent, the A_Event external function waits until it receives one. When a ROUTE REQUEST event is made available to the application, it reflects information in an ASAI route-request message sent by the DEFINITY G3 switch. Note that the A_Event external function is also used within monitoring applications to retrieve other types of events as discussed later.

Once a ROUTE REQUEST event is received in a application and the application determines where the call should be routed, the A_RouteSel external function is used to cause a route-select message to be passed back to the DEFINITY G3 switch. This in turn causes the call to be routed to the desired destination. Unlike voice response applications, routing applications are not associated with a particular call. A single routing application handles route requests for many calls. A routing application is designed to receive and process ROUTE REQUEST events. Because these events are controlled by vector processing on the DEFINITY G3 switch, they can arrive at any point in time. Hence, the primary difference between routing applications and voice response applications is that once they are activated, routing applications run continuously. Routing applications, therefore, have the following general structure:

1. An A_Event external function to wait for and retrieve a ROUTE REQUEST event from lower-level ASAI software on the Avaya IR system. Once the A_Event external function retrieves a ROUTE REQUEST event, the actions below are executed.
2. Other IVR Designer nodes that make use of the data made available in the ROUTE REQUEST event to determine where to route the call. Examples include read table and get/send host screen nodes to retrieve routing information from a local or host database.
3. An A_RouteSel external function to pass the routing information (that is, desired destination) from the application to lower-level ASAI software on the Avaya IR system. This causes an ASAI route-select message containing the routing information to be sent to the DEFINITY G3 switch.

A routing application can use any of the information returned in the ROUTE REQUEST event. Examples include the called-party number (for example, DNIS), calling party number (for example, ANI), and switch data (that is, touch-tone digits collected using the Call Prompting feature). Any one or combination of the data items returned in a ROUTE REQUEST event can be used as the basis for a routing decision.

The call is routed to the destination that is supplied in the Destination Number field of A_RouteSel. The destination can be on-switch (for example, station, ACD split, or VDN) or off-switch (for example, Direct Distance Dialing [DDD] number). Also, the call can be routed to a specific agent within an ACD split (direct agent routing). To do this, set the Destination Number field in A_RouteSel to the desired agent extension and the Split Extension field to the split logged into by the agent. Direct-agent routing is the preferred way to route calls to specific ACD agents since direct-agent calls are included in the calculations for ACD split statistics, for example, average speed of answer.

Monitoring application design

Monitoring applications on the Avaya IR system are used to support data screen delivery applications. The Notification capability of ASAI is used to track the progress of calls that are delivered to agents. A monitoring application on the Avaya IR system receives information about these calls and forwards this information to a host application. The host application in turn uses the information to format a data screen that is presented to agents receiving calls. Note, therefore, that the delivery of data screens is not a function of the Avaya IR system itself.

In data screen delivery applications, calls are not physically delivered to a telephony channel on the Avaya IR system. Rather, calls are delivered to ACD agents on the DEFINITY G3 switch. Note, however, that a call may have previously been delivered to a telephony channel to collect information from the caller.

Events

Use the A_Event external function to design a monitoring application. When used in monitoring applications, the A_Event external function returns the types of call events described in the following table.

The three call event types passed to a monitoring application reflect information contained in ASAI event reports for the call.

General structure

Unlike voice response applications, monitoring applications are not associated with a particular call. A single monitoring application handles call events for all of the calls that are delivered to a particular domain. A monitoring application is designed to receive and process call events that can arrive at any point in time as determined by how and when calls progress on the DEFINITY G3 switch. Hence, the primary difference between monitoring applications and voice response applications is that once activated, monitoring applications run continuously. Monitoring applications, therefore, have the following general structure:

1. An A_Event external function to wait for and retrieve a call event from lower-level ASAI software on the Avaya IR system. Once the A_Event external function retrieves a call event, the actions below are executed.
2. Other IVR Designer nodes are used to pass data to a host. Examples include get/send host screen nodes to send the data to an IBM host via the standard 3270 interface and a custom external function to pass the data to a custom DIP supporting an asynchronous interface.

A monitoring application can pass any combination of call-event types to a host. In addition, any combination of the data elements returned in a specific call event can be passed to a host. Examples include the called party number (for example, DNIS), calling party number (for example, ANI), and switch data (that is, call prompting information).

If you make changes to an existing monitoring application or add a new monitoring application, you must do one of the following:

1. Disable and then reenable the domain.
2. Stop and restart the voice system to activate the new application.

Call-flow scenarios

Monitoring applications on the Avaya IR system can be used to support data screen delivery for the following three different call-flow scenarios:

• Avaya IR system-to-agent transfers – In this scenario, calls are initially delivered to the system and then transferred from the Avaya IR system to a live agent. The transferred call can be monitored with a VDN type or ACD type of monitoring application if the call is transferred to a monitored VDN or ACD split domain. The transferred call can also be monitored with a CTL type of monitoring application that allows the call to be transferred to a nonmonitored domain or individual station. If the Data field of A_Tran was used to save voice application data, this data is made available in the Avaya IR system Data field of call events that are sent to the monitoring application. Hence, data screens that are delivered to agents in this scenario can be based on information that is collected in a voice application in addition to ASAI information such as ANI, DNIS, and call-prompting information that is collected by the DEFINITY G3 switch.
• Incoming call directly to agent – In this scenario, monitored VDNs or ACD splits deliver incoming trunk calls directly to live agents. Here, call events are passed to a VDN type or ACD type of monitoring application and contain ASAI-related information such as ANI, DNIS, and/or call-prompting information. Data screens are not based on data that is collected in a voice application since a Avaya IR system voice application is not used to collect data from the caller. Since the Avaya IR system does not service calls in this scenario, no data is present in the Avaya IR system Data field of call events.
• Agent-to-agent transfers – In this scenario, calls are transferred between live agents. For example, screening agents can be used to collect information from the caller and handle simple transactions. The call can subsequently be transferred to specialized agents who can handle more complex or detailed transactions. In these scenarios, data screens can be based on information that is keyed in to the host application by live agents. The host application can save the data that is collected and entered by a screening agent and then use this data as the basis for data screens that are delivered to other, specialized agents who can receive the call. The agent-to-agent transfer can be placed to a monitored domain or to an individual station and monitored with a VDN type or ACD type of monitoring application. Note that the call might have first been delivered to the Avaya IR system and then transferred to an agent prior to the live agent-to-agent transfer. Hence, call events passed to the monitoring application in this scenario can contain the same information that is available for the other two call-flow scenarios. ASAI-related information such as ANI, DNIS, and call-prompting information and Avaya IR system data can be present in call events. This information can be used in conjunction with data that is entered by a live agent to provide the basis for data screens.

© 2006 Avaya Inc. All Rights Reserved.