- 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:
- Find out which channel group is assigned to the trunk (by using Pack
Configuration is the quickest method).
- Find out which Signaling Type is specified in the Channel Group definition
(by using System Configuration).
- 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.