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.