Dial, MakeCall, or TransferCall actions behave unexpectedly

When a voice application produces unexpected results from a Dial, MakeCall, or TransferCall action, check the following:

Are the values of the controlling system parameters correct?
How Dial, MakeCall, and TransferCall behave is partially controlled by the values of the Maximum Ring Time, Maximum Ring Wait, and Maximum Dial Tone Wait parameters in the Application Server Interface parameter group. Use the information provided in Blueworx Voice Response for AIX: Configuring the System to check these values and if necessary, redefine them. Make sure that Blueworx Voice Response is configured to expect or not expect a dial tone by checking the value of the Dial Tone Detection parameter.

For more information about defining Dial, MakeCall, and TransferCall, see Blueworx Voice Response for AIX: Application Development using State Tables.

Is the telephone line in the expected state?
The operation of Dial and TransferCall assume that the voice application is running on a channel that is already active (handling an in-progress call). MakeCall, however, requires a free channel for the action to run correctly. Ensure that the Dial and TransferCall actions in the state table are preceded by an AnswerCall (to begin processing an inbound call) or MakeCall (to originate an outbound call). Ensure that nothing in the state table instructs the application to connect a channel and begin handling a call before the MakeCall action is run.

For more information about the operation of Dial, MakeCall, and TransferCall, see Blueworx Voice Response for AIX: Application Development using State Tables.

Is your switch protocol FXS loop start?
MakeCall might occasionally fail if your switch protocol is FXS loop start. Because glare conditions cannot be detected reliably on loop start, MakeCall fails when an inbound call and an outbound call attempt to use the same channel at the same time. In this situation, Blueworx Voice Response flags a B-bit fault error and posts an alarm to the System Monitor.

You can remove this problem if you configure the trunk channels to handle either inbound calls or outbound calls but not ‘bothway’calls. If you need bothway channels, you can minimize the likelihood of this problem occurring. To do this, configure the switch and any hunt group to locate a free channel for an inbound call (beginning with the first channel on the trunk), and for an outbound call (beginning with the last channel). This configuration significantly reduces the possibility for collision between an inbound call and an outbound call attempting to use the same channel at the same time.

For more information about defining channel groups and the System Monitor, see Blueworx Voice Response for AIX: Configuring the System.

Does your switch have unique requirements?
Your configuration might require particular signals that are unique to your switch. For example, for a TransferCall action to complete successfully, the ROLM switch requires a Dial action with hook flash before the TransferCall action . Check the signaling requirements of your switch and ensure that all necessary states are implemented in your state table.

For information that is specific to the requirements of your switch, see your telephone provider.

Is the digit string format definition correct?
The stream of signals that is sent to a switch to obtain a dial tone, make an outbound call, or transfer a call is not the same for all switches. Use the information about Dial, MakeCall, and TransferCall that is provided in Blueworx Voice Response for AIX: Application Development using State Tables to ensure that the digit string format specified in the TransferCall action is correct for your switch.
Are you using a signaling process that you developed yourself?
Check whether your signaling process is still running. Message 32011 in the error log indicates that a signaling process has terminated.

Did your signaling process specify SL_SIGPROC_CAPABILITY_TRANSFER when it called the sl_open() subroutine?

Is the state table using the TransferCall action or the Dial action? You should use the TransferCall action in your state tables because the Dial action does not work when you are using a signaling process.

Check that your signaling process is receiving the SL_CALL_TRANSFER_REQ primitive.

Check that your signaling process is returning the SL_CALL_TRANSFER_CNF primitive to Blueworx Voice Response and that the sl_send_confirm() subroutine is returning successfully.

Use signaling interface tracing to see the primitive that Blueworx Voice Response sent to your signaling process. For information on tracing signaling interfaces, see Blueworx Voice Response for AIX: Programming for the Signaling Interface.