How does Blueworx Voice Response answer an incoming call?

When Blueworx Voice Response receives an incoming call it uses the call's application profile ID to determine how it should be answered.

Initially, control of the call is always passed to the Incoming_Call state table. Incoming_Call issues the AnswerCall action then the InvokeStateTable action to invoke the state table specified in the application profile.

If the application profile specifies a state table called JavaApplication and the Java and VoiceXML environment is installed and running, control of the call passes to a Java application. The JavaApplication state table needs to be available in case the Java and VoiceXML environment is not running. For more information on configuring your system to answer incoming calls with Java applications, see Blueworx Voice Response for AIX: Deploying and Managing VoiceXML and Java Applications.

Each state table that is designed to handle incoming calls therefore requires an application profile, and Blueworx Voice Response must find the appropriate application profile before Incoming_Call can invoke the right state table to handle the call.

Figure 1. How Blueworx Voice Response finds the state table to handle an incoming call
Flow chart showing how matches an incoming call to a state table. If receives a called number it checks for an application profile to match the called number. Otherwise it checks for an application profile to match the channel identification. When an application profile is found, finds and invokes the state table specified by the application profile. If the state table is called Java Application control passes to the Java and voiceXML environment. If could not find a matching application profile it invokes a default application if one is available or does not answer the call.

How does Blueworx Voice Response find the application profile?

Incoming_Call works on the basis that an application profile specifying a state table has been found. Figure 1 shows how Blueworx Voice Response finds the application profile. When a call comes in and the called number is available, Blueworx Voice Response looks for an application profile whose ID matches the called number. If the called number is unavailable for any reason, Blueworx Voice Response looks for an application profile whose ID matches the channel identification (for details, see the Blueworx Voice Response for AIX: Configuring the System information). If no profile is found, Blueworx Voice Response looks for an application profile whose ID matches the value of the System Default Application Profile system parameter (whose supplied value is 0000000000).

If there is no qualifying application profile ID, the call is not answered.

Table 1. Application profile examples

Profile ID

State Table Name

Function

1234567

Accounts_Main

Tell callers their account details.

1238800

Interest_Main

Tell callers the current interest rates.

0000000000

Main

Offer callers a choice of services.

What happens when Incoming_Call answers the call?

After issuing the AnswerCall action, the Incoming_Call state table invokes the state table specified in the application profile. Because it invokes the state table by application profile, Incoming_Call cannot pass any parameters to the state table. The following system variables are, however, available for the state table to use:

Application - Profile ID (SV22)
The ID of the application profile found by Blueworx Voice Response.
System : Call Info : Called Number (SV185)
The called number or, if no called number is available, the channel identification.
Caller - Profile ID (SV20)
The calling number (if available).
System : Call Info : Calling Number (SV186)
The calling number (if available).
System : Call Info : Call info status (SV129)
Indicates whether call information (called number and calling number) was received. If the value of this variable is 1 (successful), SV185 is the called number; if the value is 0 (undefined) or 2 (failed), it is the channel identification.

What happens if the state table is invalid?

If there is a problem with the state table specified in the application profile, for example, if it is not found or is invalid, Incoming_Call invokes another supplied state table, Welcome, which greets the caller and hangs up. Welcome is also invoked during the installation test described in the Blueworx Voice Response for AIX: Installation information: Blueworx Voice Response finds the application profile whose ID is 0000000000, and this application profile specifies Welcome as the state table.

Do Incoming_Call and Welcome need customizing?

Incoming_Call and Welcome are set up and ready to use. You should record a new voice segment for Welcome to play, perhaps explaining to the caller that the system is experiencing technical difficulties.

Both of these applications are imported into Blueworx Voice Response as part of the installation process.

Do not delete the state table specified in the State Table Name for Incoming Calls parameter (Incoming_Call), because Blueworx Voice Response cannot answer calls without it. Do not delete the application profile specified in the System Default Application Profile parameter (0000000000), because Blueworx Voice Response may need it to answer a call if no other application profile can be found.

If they get modified or deleted by mistake, you can reimport them from /usr/lpp/dirTalk/sw/samples/BaseData.imp.

Can you write your own state table to answer calls?

If you prefer to write your own state table to answer incoming calls, you can. If you choose a different name for it, you must change the State Table Name for Incoming Calls parameter in the Application Server Interface parameter group (after you've done this, you need to stop Blueworx Voice Response and start it again to make the new value take effect).

If your “state table for incoming calls” does not include an AnswerCall action, each state table invoked by it must include its own AnswerCall action.

Ayava switches send DNIS information as DTMF keys after Blueworx Voice Response answers the call, instead of using the incoming address signaling options. To use such switches with Blueworx Voice Response you must either customize the state table identified by the system parameter: State Table Name for Incoming Calls (the default is Incoming_Call) or substitute one of your own.

The customized state table must include the GetData action immediately after the AnswerCall action. The KeyBuffer, Minimum, Maximum, and Timeout parameters for the GetData action should be set according to the length of the DNIS digits and the expected time to receive all digits.

If you want to use the received digits to select the application profile, add an AssignData action to set SV22 with the received digits before calling the InvokeStateTable action.

Handling incoming calls in your production system

Even if you do not change Incoming_Call, there are several method of handling incoming calls, and your decision partly depends on the capabilities of the switch to pass the called number on to Blueworx Voice Response. You need to decide whether to:

Have one state table to handle all incoming calls:

With this method, the state table asks the caller which service they require, and invokes another state table. You only need one application profile to make this work: you can use one of the following methods:

  • Make the application profile ID match the value of the System Default Application Profile parameter in the General system parameters group
  • Give all your channels the same identification (the same area code and phone number) and make the application profile ID match this.
    Figure 2. Application profile needed with one state table for all
    The small blue window shows a box in the top left corner containing ten zeros.
Choose the state table on the basis of the called number:

With this method, Blueworx Voice Response can respond with the appropriate voice response service for each caller. Each caller dials a different number depending on which service they require, and gets straight through to that service. In the example shown in Table 1, callers dial 1234567 for the accounts application (Accounts_Main) or 1238800 for the interest rates application (Interest_Main).

Figure 3. Application profiles needed when using called number
The small blue window shows a box in the top left corner containing ten zeros. Two boxes to the right contain (top) 1 2 3 4 5 6 7 and (bottom) 1 2 3 8 8 0 0

You should have one application profile for each state table that might be invoked in this way. You also need a default application profile and state table. Typically, the default state table would ask the caller which service they require, in the event that the called number is, for some reason outside your control1, unavailable.

Dedicate a group of channels to each voice response service:

This method has the same advantage as choosing the state table on the basis of called number. The disadvantage of this method is that it ties channels to specific applications, which is inefficient if all the calls at one time are for one of the applications: it makes load-balancing difficult. If it's possible to get the called number from the switch, you should use that method.

Again, you need one application profile for each state table that might be invoked in this way.

Figure 4. Application profiles needed when using channel identification
The small blue window shows two boxes to the right containing (top) 1 2 3 4 5 6 7 and (bottom) 1 2 3 8 8 0 0
Parent topic: Answering calls
1 The called number may be unavailable if, for example, the switch did not receive the full information, or because the task the switch uses to send the information is busy.