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.
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 the called number was received on an exchange data link, the area code specified in the channel group is concatenated to the beginning of the number before the search.) If the called number is unavailable for any reason, Blueworx Voice Response searches for an application profile whose ID matches the channel identification (for details, see Channel identification). 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.If Blueworx Voice Response is configured to go off hook before attempting to get call information (see EDL Call Information After Off Hook), the system plays the caller a message saying that there are technical difficulties, and then hangs up.
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. |
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:
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.
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 your channels are controlled by a CCS signaling process such as ISDN or SS7, you can customize Incoming_Call 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.
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.
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:
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:
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.