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 should always be available so it can be invoked if 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 correct application profile before Incoming_Call can invoke the correct state table to handle the call.
How does Blueworx Voice Response find the application profile?
Incoming_Call assumes 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 searches for an application profile whose ID matches the called number. 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 no qualifying application profile ID is found, the call is not answered.
| 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 calls the state table specified in the application profile. Because it calls the state table by application profile, Incoming_Call cannot send 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 not valid?
If a problem occurs with the state table that is specified in the application profile, for example, if it is not found or is not valid, Incoming_Call calls another supplied state table, Welcome, which greets the caller and hangs up. Welcome is also called during the installation test that is 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.
If you wish Incoming_Call can be customized to make use of call setup information contained in the Call Info: Info In System Variable (SV542). The information is available at the onset of the state table and is then overwritten when the AnswerCall action is issued. For more information, see Blueworx Voice Response for AIX: Application Development using State Tables.
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 might need it to answer a call if no other application profile can be found.
If the state table or application profile are 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 have changed the name, stop then start Blueworx Voice Response to make the new value take effect).
If your “state table for incoming calls” does not include an AnswerCall action, each state table that is called by it must include its own AnswerCall action.
Handling incoming calls in your production system
If you do not change Incoming_Call, several methods of handling incoming calls are still available, and your decision partly depends on the capabilities of the switch to send the called number on to Blueworx Voice Response. You must decide whether to:
- Have one state table to handle all incoming calls
- Choose the state table on the basis of the called number
- Dedicate a group of channels to each voice response service, and let the switch make the decision with reference to the called number
With this method, the state table asks the caller which service is required, and calls another state table. You need only 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 Blueworx Voice Response parameters group
- Give all your channels the same identification (the same area code and phone number) and make the application profile ID match this identification.
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 is required, and gets directly 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).
You should have one application profile for each state table that might be called in this way. You also need a default application profile and state table. Typically, the default state table asks the caller which service is required, in the event that the called number is unavailable for some reason outside your controlThe called number might 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..
This method is the most effective of the three methods that are described in this section. However, if your switch cannot send the called number to Blueworx Voice Response, you cannot use this method.
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 is 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.