Blueworx Voice Response cannot
use a trunk unless a digital trunk adapter (DTTA is installed
in the Power System 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 Power System. 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 contact 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.