Cannot enable trunk

Blueworx Voice Response cannot use a trunk unless a digital trunk adapter (DTTA is installed in the pSeries computer to process the signals that are transmitted by the switch. A trunk status of Available indicates that a digital trunk adapter is physically present (is available) to handle the signals from that trunk.

The way to inform Blueworx Voice Response that additional digital trunk adapters are installed is to enable the trunks to which they are connected. The enabling of a trunk informs Blueworx Voice Response that the digital trunk adapter has been installed. (If you are looking at the System Monitor, you can see that after you enable a trunk, the trunk status displayed at the top of the graphic is Available.) When you cannot enable additional trunks, check the following:

Is the digital trunk adapter installed?
Check that the trunk cable is installed and that the cable is connected properly (you may need to try reseating it). Check that the trunk has been configured with some channel licenses. Also check that the dt_setowner command has been issued for each DTTA, see Blueworx Voice Response for AIX: Installation.
Have you tried recycling Blueworx Voice Response?
Use the information provided in Blueworx Voice Response for AIX: Configuring the System to reset the Operating Status parameter for the trunk to Available. Then use this information to recycle Blueworx Voice Response (shut it down and restart it). If necessary, also try restarting the pSeries computer. If you do, ensure that you shut down Blueworx Voice Response first.
Has the switch disabled your trunk?
If you have been enabling and disabling the trunk frequently, or have been experimenting with the telephony configuration, the switch to which you are connected may have decided that there is something wrong with the trunk. In this case, the switch may disable the trunk temporarily or permanently. Your telephone provider can tell you if the switch has disabled the trunk.
Trunk configured for ISDN does not enable using System Monitor
Check whether any warnings are visible in the alarm windows. These can help you solve the problem, as described below:
27046 SDI failed to enable a pack because a signaling process was missing
The process name is given at the end of the alarm parameters. This custom server might not have been started or installed. This error can also occur if the system was configured to run with two different types of ISDN; for example, AT&T 5ESS Versions 5E8 and 5E9, which is not allowed. Only one ISDN custom server can be run at a time.

You can resolve this by checking whether the correct ISDN custom server is installed and running. If it is, shutdown and restart Blueworx Voice Response.

29604 ISDN Layer 2 opening/closing D channel via Device Driver
This problem occurs when an ISDN Layer 2 process is still active because of a previous problem, and a new ISDN Layer 2 process is started. The file descriptor is being held by the original process for the device driver, and cannot be reopened.

You can solve this by shutting down and restarting the system; this action cleans up any old ISDN processes that are still running in the system. If this problem happens frequently call Blueworx Support.

29609 ISDN Layer 2 Internal Error29403 ISDN Layer 3 Internal Error
These messages occur when a fatal error has occurred on one of the signaling channels on ISDN. Parameters are logged in the error log, and Blueworx Voice Response System Management attempts to restart the trunk automatically.

If the trunk does not restart automatically, Disable then Enable it manually. If this action has no effect, disable all trunks, then stop and restart the ISDN custom server. The trunks should then enable.

Take a note of these alarm parameters and contact Blueworx Support.

Are you using a signaling process that you developed yourself?
Check whether your signaling process is still running. Message 32011 indicates that a signaling process has terminated.

Check whether your signaling process is receiving the SL_TRUNK_ENABLE_REQ primitive.

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

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