Blueworx Voice Response does not answer the phone

When Blueworx Voice Response does not answer the telephone, check the following:

Is at least one trunk in service?
Before Blueworx Voice Response can answer the telephone, at least one of the trunk lines that connects the adapter to the telephone network must have the status InService. Blueworx Voice Response for AIX: Configuring the System describes how to activate a trunk. Either use this information to reset the value of the Operating Status parameter that controls trunk initialization status and recycle Blueworx Voice Response (shut it down and restart it), or use the System Monitor to activate one trunk dynamically.
Is at least one channel configured as Incoming or Bothway?
Unless at least one channel on an InService trunk is configured to accept incoming calls, Blueworx Voice Response cannot respond to an incoming call. Check the Direction setting for each trunk, using Pack Configuration.
Is the Ringing On Minimum parameter short enough?
In some telephone systems, internal and external calls are signalled differently. For example, an external call might be a one-second ring, while an internal call is two 0.5-second rings. If the value of Ringing On Minimum is more than 0.5 seconds, Blueworx Voice Response cannot recognize the internal ring as a signal to answer the telephone. To correct this:
  1. Find out which channel group is assigned to the trunk (by using Pack Configuration is the quickest method).
  2. Find out which Signaling Type is specified in the Channel Group definition (by using System Configuration).
  3. Reset the value of the Ringing On Minimum parameter in the Signaling Type definition (by using System Configuration). Use Help on the Ringing On Minimum window if you need an explanation of the parameter.
Are enough channel processes available to answer calls?
When the telephone rings, Blueworx Voice Response allocates a previously started channel process to handle the incoming call. If it cannot allocate a channel process, it cannot answer the telephone. There are several reasons why this could happen:
  • The value of the maxuproc parameter, which controls the maximum number of AIX processes, is too low. The maxuproc parameter must be greater than the sum of the number of telephony channels defined and the value of extra channel processes. See Blueworx Voice Response for AIX: Installation for more information.
  • The software component that creates channel processes (called CHP) is not running.
  • The value of the parameter that controls how many extra channel processes Blueworx Voice Response can create is too low.

Channel processes are AIX user processes. Use the information in the section Blueworx Voice Response software does not start to initialize to check on the maximum number of processes that the system can run (maxuproc) and increase the value if necessary.

To find out whether the process called CHP is running, type ps | grep CHP and press Enter. If the process is not listed, recycle Blueworx Voice Response (shut it down and restart it). If the process still does not start, use the information provided in Blueworx Voice Response software does not start to initialize to ensure the entry is present in the tasklist.data file.

Blueworx Voice Response normally starts as many channel processes as there are channels, plus the number defined by the value of the Blueworx Voice Response Extra Channel Process parameter in the Application Server Interface parameter group. If you need to start more channel processes, use the information provided in Blueworx Voice Response for AIX: Configuring the System to reset the parameter.

Is Incoming_Call present?
The Blueworx Voice Response software includes a state table called Incoming_Call, which issues an AnswerCall action, then invokes the voice application. If Incoming_Call has been deleted or incorrectly modified, the call is not handled correctly.

Use the information supplied in Blueworx Voice Response for AIX: Application Development using State Tables, to list all state tables and to determine whether Incoming_Call has been changed. If Incoming_Call has been changed or is missing, use the information provided in Blueworx Voice Response for AIX: Application Development using State Tables to import the state table. Incoming_Call is in a file called /usr/lpp/dirTalk/sw/samples/BaseData.imp.

For more information on how Blueworx Voice Response answers the telephone, see Blueworx Voice Response for AIX: Configuring the System.

Have you installed an application to answer the call?
Blueworx Voice Response must be able to find an application profile that is identified with either the dialed number identification digits passed by the switch, the information that identifies the channel on which the call signals are being transmitted, or the value of the Blueworx Voice Response Default Application Profile ID parameter. For a complete explanation of how Blueworx Voice Response answers the telephone, see Blueworx Voice Response for AIX: Configuring the System.

Use the information provided in Blueworx Voice Response for AIX: Configuring the System to list all existing application profiles. If there is no qualifying profile in the Blueworx Voice Response database, use the information in Blueworx Voice Response for AIX: Configuring the System to create one.

Are there continuous ISDN Layer 3 data link activated/deactivated white alarms?
If you see the messages 29405—ISDN Layer 3 primary data link activated and 29406—ISDN Layer 3 primary data link deactivated:
On an E1 system
There is a cable or connection problem between Blueworx Voice Response and the switch.
On a T1 system
A cabling fault might have occurred, or the trunk framing mode or line coding for the ISDN signaling trunk is set incorrectly. Check that:
  • The switch is configured for Extended SuperFrame (ESF) with line coding set to B8ZS for signaling trunks
  • The trunk from the switch is not configured for CAS
  • The CSU used supports ESF and B8ZS, and that it is configured correctly
  • Blueworx Voice Response is correctly configured

If you used Pack Configuration to configure the trunk, the parameters should be correct.

Are you using ISDN with Non Facility Associated Signaling (NFAS)?
Check that you specified the correct trunk ids when you configured the system.

If you are using ISDN NFAS, your Service Provider must tell you which trunk ids to use. If you use the wrong ones, incoming calls are not answered by Blueworx Voice Response; they are be cleared by Blueworx Voice Response with a cause code of Channel Unacceptable.

Use the ISDN_MONITOR tool to check the line signaling, see The channel ID information element.

Do channels remain blocked when trunk is enabled and channels are put in service?
If you are not using Non Facility Associated Signaling (NFAS), this problem is likely to be caused by one of the following:
  • The switch is taking too long to send the RESTART ACKnowledge messages to Blueworx Voice Response (if the Send RESTART on Channel Enable parameter is set to YES in the ISDN signaling section of the System Configuration).

    You can check this by selecting “channels out of service” and then “channels in service”. The channels change to the IDLE state if the ISDN Layer 2 link to the switch is working.

  • ISDN Layer 2 from the switch is not responding.

    If the switch ISDN Layer 2 does not respond after 90 seconds, a message is logged that tells you the timer expired on the Primary ISDN Layer 3 Data Link. Use the ISDN_MONITOR tool or an ISDN Primary Rate Line monitor to monitor what the switch is doing. The switch should send out Synchronous Asynchronous Balanced Message Extended (SABME) Layer 2 frames to establish the link. These must be Command frames, not Response frames. If these frames appear on the ISDN_MONITOR trace as “Rsp” frames, the switch is set up in “Network” mode. Change the mode to “User-Side” because Blueworx Voice Response supports only this mode.

You might also get these problems if you are using NFAS on T1 systems.

However, there is another possible cause of this problem, which can show up as one or more non-signaling trunks having all their channels in BLOCKED state while some other trunks are in IDLE state.

If the ISDN trunk id does not match the trunk id configured in the switch, the RESTART ACKnowledge messages that contain the trunk id are incorrect, and the channels change to the IDLE state. This id (in the range 0 through 31) is provided by the Service Provider.

Check that the trunk ids match those that are defined on the switch. Use the ISDN_MONITOR or an ISDN Primary rate monitor to see whether RESTART ACKnowledge messages are returned with the correct trunk id values in the Channel Information Element (IE).

Are you using a signaling process that you developed yourself?
Have you configured Blueworx Voice Response to use your signaling process? (See Blueworx Voice Response for AIX: Configuring the System for more information.)

Check that your signaling process is still running. Message 32011 in the error log indicates that a signaling process has terminated.

Check that your signaling process is receiving the call from the network.

Check that your signaling process is sending the SL_CALL_SETUP_IND primitive to Blueworx Voice Response, and that the sl_send_indication() subroutine is returning successfully.

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