Avaya Interactive Response User Manual
Avaya™ Interactive Response
Release 2.0
Troubleshooting
issue 1.0
Publication Date: April 2006
Issue 1.0 April 2006 1
© 2005 - 2006 Avaya Inc. All Rights Reserved.
Notice
While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no
liability for any errors. Changes and corrections to the information in this document might be incorporated in future releases.
Documentation disclaimer
Avaya Inc. is not responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications,
additions, or deletions were performed by Avaya. Customer and/or End User agree to indemnify and hold harmless Avaya, Avaya's agents, servants and
employees against all claims, lawsuits, demands and judgments arising out of, or in connection with, subsequent modifications, additions or deletions to this
documentation to the extent made by the Customer or End User.
Link disclaimer
Avaya Inc. is not responsible for the contents or reliability of any linked Web sites referenced elsewhere within this documentation, and Avaya does not necessarily
endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all the time and we have no control
over the availability of the linked pages.
Warrant y
Avaya Inc. provides a limited warranty on this product. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya's standard
warranty language, as well as information regarding support for this product, while under warranty, is available through the Avaya Support Web site:
http://www.avaya.com/support
License
USE OR INSTALLATION OF THE PRODUCT INDICATES THE END USER'S ACCEPTANCE OF THE TERMS SET FORTH HEREIN AND THE GENERAL
LI C EN S E T ERM S AVAIL A BL E ON TH E AVAYA WE B S I TE h tt p :/ / support.avaya.com/LicenseInfo/ ("GENERAL LICENSE TERMS"). IF YOU DO NOT WISH TO BE
BOUND BY THESE TERMS, YOU MUST RETURN THE PRODUCT(S) TO THE POINT OF PURCHASE WITHIN TEN (10) DAYS OF DELIVERY FOR A REFUND
OR CREDIT.
Avaya grants End User a license within the scope of the license types described below. The applicable number of licenses and units of capacity for which the
license is granted will be one (1), unless a different number of licenses or units of capacity is specified in the Documentation or other materials available to End
User. "Designated Processor" means a single stand-alone computing device. "Server" means a Designated Processor that hosts a software application to be
accessed by multiple users. "Software" means the computer programs in object code, originally licensed by Avaya and ultimately utilized by End User, whether as
stand-alone Products or pre-installed on Hardware. "Hardware" means the standard hardware Products, originally sold by Avaya and ultimately utilized by End
User.
License type(s)
Concurrent User License (CU). End User may install and use the Software on multiple Designated Processors or one or more Servers, so long as only the licensed
number of Units are accessing and using the Software at any given time. A "Unit" means the unit on which Avaya, at its sole discretion, bases the pricing of its
licenses and can be, without limitation, an agent, port or user, an e-mail or voice mail account in the name of a person or corporate function (e.g., webmaster or
helpdesk), or a directory entry in the administrative database utilized by the Product that permits one user to interface with the Software. Units may be linked to a
specific, identified Server.
Shrinkwrap License (SR). With respect to Software that contains elements provided by third party suppliers, End User may install and use the Software in
accordance with the terms and conditions of the applicable license agreements, such as "shrinkwrap" or "clickwrap" license accompanying or applicable to the
Software ("Shrinkwrap License"). The text of the Shrinkwrap License will be available from Avaya upon End User's request (see "Third-party Components" for more
information).
Copyright
Except where expressly stated otherwise, the Product is protected by copyright and other laws respecting proprietary rights. Unauthorized reproduction, transfer,
and or use can be a criminal, as well as a civil, offense under the applicable law.
Third-party components
Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements ("Third Party Components"),
which may contain terms that expand or limit rights to use certain portions of the Product ("Third Party Terms"). Information identifying Third Party Components and
the Third Party Terms that apply to them is available on the Avaya Support Web site:
http://support.avaya.com/ThirdPartyLicense/
Preventing toll fraud
"Toll fraud" is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent,
subcontractor, or is not working on your company's behalf). Be aware that there can be a risk of toll fraud associated with your system and that, if toll fraud occurs,
it can result in substantial additional charges for your telecommunications services.
Avaya fraud intervention
If you suspect that you are being victimized by toll fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline
at +1-800-643-2353 for the United States and Canada. For additional support telephone numbers, see the Avaya Support Web site:
http://www.avaya.com/support
Providing Telecommunications Security
Telecommunications security (of voice, data, and/or video communications) is the prevention of any type of intrusion to (that is, either unauthorized or malicious
access to or use of) your company's telecommunications equipment by some party.
Your company's "telecommunications equipment" includes both this Avaya product and any other voice/data/video equipment that can be accessed by this Avaya
product (that is, "networked equipment").
An "outside party" is anyone who is not a corporate employee, agent, subcontractor, or is not working on your company's behalf. Whereas, a "malicious party" is
anyone (including someone who might be otherwise authorized) who accesses your telecommunications equipment with either malicious or mischievous intent.
Such intrusions might be either to/through synchronous (time-multiplexed and/or circuit-based), or asynchronous (character-, message-, or packet-based)
equipment, or interfaces for reasons of:
• Utilization (of capabilities special to the accessed equipment)
• Theft (such as, of intellectual property, financial assets, or toll facility access)
• Eavesdropping (privacy invasions to humans)
• Mischief (troubling, but apparently innocuous, tampering)
• Harm (such as harmful tampering, data loss or alteration, regardless of motive or intent)
Issue 1.0 April 2006 2
Troubleshooting overview
Be aware that there might be a risk of unauthorized intrusions associated with your system and/or its networked equipment. Also realize that, if such an intrusion
should occur, it might result in a variety of losses to your company (including but not limited to, human/data privacy, intellectual property, material assets, financial
resources, labor costs, and/or legal costs).
Responsibility for Your Company's Telecommunications Security
The final responsibility for securing both this system and its networked equipment rests with you - Avaya's customer system administrator, your
telecommunications peers, and your managers. Base the fulfillment of your responsibility on acquired knowledge and resources from a variety of sources including
but not limited to:
• Installation documents
• System administration documents
• Security documents
• Hardware-/software-based security tools
• Shared information between you and your peers
• Telecommunications security experts
To prevent intrusions to your telecommunications equipment, you and your peers must carefully program and configure:
• Your Avaya-provided telecommunications systems and their interfaces
• Your Avaya-provided software applications, as well as their underlying hardware/software platforms and interfaces
• Any other equipment networked to your Avaya products
TCP/IP Facilities
Customers might experience differences in product performance, reliability and security depending upon network configurations/design and topologies, even when
the product performs as warranted.
Standards Compliance
Avaya Inc. is not responsible for any radio or television interference caused by unauthorized modifications of this equipment or the substitution or attachment of
connecting cables and equipment other than those specified by Avaya Inc. The correction of interference caused by such unauthorized modifications, substitution
or attachment is the responsibility of the user. Pursuant to Part 15 of the Federal Communications Commission (FCC) Rules, the user is cautioned that changes or
modifications not expressly approved by Avaya Inc. might void the user's authority to operate this equipment.
Federal Communications Commission Statement
Part 15:
Note:
This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits
are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment
generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference
to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to correct
the interference at his own expense.
Canadian Department of Communications (DOC) Interference Information
This Class A digital apparatus complies with Canadian ICES-003.
Cet appareil numérique de la classe A est conforme à la norme NMB-003 du Canada.
This equipment meets the applicable Industry Canada Terminal Equipment Technical Specifications. This is confirmed by the registration number. The abbreviation,
IC, before the registration number signifies that registration was performed based on a Declaration of Conformity indicating that Industry Canada technical
specifications were met. It does not imply that Industry Canada approved the equipment.
European Union Declarations of Conformity
Avaya Inc. declares that the equipment specified in this document bearing the "CE" (Conformité Europeénne) mark conforms to the European Union Radio and
Telecommunications Terminal Equipment Directive (1999/5/EC), including the Electromagnetic Compatibility Directive (89/336/EEC) and Low Voltage Directive
(73/23/EEC).
Copies of these Declarations of Conformity (DoCs) can be obtained by contacting your local sales representative and are available on the Avaya Support Web site:
http://www.avaya.com/support
Trademarks
Avaya, the Avaya logo, and Interaction Reponse, are either registered trademarks or trademarks of Avaya Inc. in the United States of America and/or other
jurisdictions.
All other trademarks are the property of their respective owners.
Downloading documents
For the most current versions of documentation, see the Avaya Support Web site:
http://www.avaya.com/support
Avaya support
Avaya provides a telephone number for you to use to report problems or to ask questions about your product. The support telephone number is 1 800 242 2121
in the United States. For additional support telephone numbers, see the Avaya Support Web site:
http://www.avaya.com/support
Issue 1.0 April 2006 3
Contents
Troubleshooting ..................................................................................................................... 6
Troubleshooting overview ............................................................................................... 6
Requirements for successful operations....................................................................... 6
Possible malfunctions and errors.................................................................................. 8
Identifying possible causes of problems ..................................................................... 10
Troubleshooting procedure ........................................................................................... 12
Using IR system events ..............................................................................................13
Gathering information on a problem ........................................................................... 13
Troubleshooting based on observations ....................................................................... 15
Investigating operations problems ..............................................................................16
Checking communications..........................................................................................36
Checking hardware.....................................................................................................43
Index ...................................................................................................................................... 61
Issue 1.0 April 2006 5
Contents
Troubleshooting
An Avaya IR system interacts with other systems and relies on them for critical functions.
Consequently, troubleshooting may involve testing connections and checking other systems
where databases, speech functions, and host services reside. This section guides you in
resolving many Avaya IR system problems and includes information on basic LAN, server,
and host troubleshooting. Additionally, Avaya technical support provides troubleshooting
assistance that is specific to your Avaya IR system and the current problem.
This section includes the following topics:
Troubleshooting overview ................................................................. 6
Troubleshooting procedure ............................................................. 12
Troubleshooting based on observations ......................................... 15
Troubleshooting overview
This overview explains how the Avaya IR system works and and identifies potential problem
Requirements for successful operations
The public switched telephone network (PSTN)
areas.
Interactions between the IR system and other systems and applications are essential to voice
response operations. This section explains the requirements for successful operations to help
you to prevent problems and identify them more quickly when they occur.
Calls come into the IR system from the public switched telephone network (PSTN). Calls
from the PSTN can reach the IR system in one of three ways:
• A MultiVantage (DEFINITY) system receives the calls from the PSTN and passes them to
the IR system through direct digital connections between the two systems.
6 Avaya IR R2.0 Troubleshooting
Contents
• An IP-enabled DEFINITY or MultiVantage system receives calls from the PSTN, converts
them to packet-based signals, and sends them to the IR system over a Local Area
Network (LAN) connection.
• Calls come from the PSTN directly to the IR system through digital connections.
For successful voice response operations, all of the connections described above and the
telephony network that supports them–including central offices–must be working and free
from errors.
Switches
IR systems can be linked to DEFINITY or MultiVantage systems that route calls to and from
the IR system and perform call handling functions. For successful operations, switches must
be free of hardware problems and must be administered correctly. Additionally, connections
between the switch and the IR system must be operating properly and not be overloaded.
DEFINITY and MultiVantage systems come with a comprehensive set of self-tests that you
can use to troubleshoot problems with the switch and with connections, such as trunks.
Procedures are documented in detail in the various administration manuals. Switch
troubleshooting should be done with the aim of bringing connections into service. Once the
connections are in service, there is a good chance that the problem is not with the switch.
Voice response applications
Voice response applications manage the interactions between callers and play the
information that callers hear. For successful operations, voice response applications must
perform a variety of tasks, such as:
• Interpreting caller input and taking appropriate action
• Communicating with hosts, databases, and proxy speech servers
• Transferring values entered by callers to other applications
• Providing information to callers in the form of recorded speech or speech generated
through the Proxy Text-to-Speech feature
As you can see, voice response applications are central to the successful operation of an IR
system.
Connections and communications
Connections to other systems, and the communications that take place across them, are
critical to smooth voice operations. Major connections and communications are as follows:
Issue 1.0 April 2006 7
Contents
• Digital lines and LAN connections that bring calls in from and send calls out to the public
switched telephone network (PSTN)
• Connections between any MultiVantage systems and the IR system
• Connections from the back of the IR system to other devices, and to the LAN
• LAN connections between the IR system and servers that provide speech functions,
database information, or both
System and LAN capacity
A breakdown in any of these connections can affect voice response operations.
Like any computer, the IR system has a certain amount of memory, drive space, and CPU
capacity to support system operations. Additionally, the IR system requires LAN capacity to
communicate with servers that provide critical functions. For successful operation, both IR
system capacity and LAN capacity must be adequate.
Possible malfunctions and errors
Hardware malfunctions and failures
This section explains the types of problems that may affect voice response operations.
Hardware malfunctions and failures may stop or interfere with voice operations. These
include problems in:
• The IR system itself
• Servers providing speech functions, database information, or both
• Connected MultiVantage (DEFINITY) systems
Hardware malfunctions and failures are relatively easy to identify. However, they are rarely a
cause of problems.
Incorrect system administration
Errors in IR system administration can cause problems with voice operations. Examples are:
• A service cannot be assigned to a channel, resulting in the service not functioning when
calls come in.
8 Avaya IR R2.0 Troubleshooting
Contents
• TCIP/IP connections between the IR system and a server might be set up incorrectly, so
that required data is not available to callers.
Application errors
Applications manage voice response functions, so errors can be devastating to operations.
For instance, an application may call for the playing of recorded speech that does not exist,
or try to access the wrong server for speech. Applications that are not sufficiently tested, or
that are not tested under realistic conditions, can function poorly when used for business
operations. Voice response applications that are large and complex or that use system
resources inefficiently are the most common cause of performance problems.
Connection and communication problems
When any connection that supports voice response applications experiences a problem,
operations may be affected. Disruptions may occur in the public switched telephone network
(PSTN), MultiVantage (DEFINITY) system, servers that support operations, or in the LAN.
Circuit-based configurations
Circuit-based configurations allocate a physical cable (or part of a cable by using Time
Division Multiplexing) to each telephone call. Obviously, problems with these cables might
affect voice response applications.
Packet-based configurations
When the VoIP feature is used, the voice data is transmitted in small packets that contain a
fraction of the entire spoken transmission. Rather than a dedicated cable being used
between the end-points, packets traverse the network between the end-points via one or
more available routes. With this type of transmission, packets may get lost. An overloaded
network might delay or lose packets.
Overloading
Overloading may occur in these ways:
• An overloaded IR system exhibits performance problems. Causes of system overloaded
include:
― Voice response applications that use system resources inefficiently or are too complex
or lengthy
― Excessive system processes that are external to voice response operations
Issue 1.0 April 2006 9
Contents
Speech
• LAN overloading may result from competition with other processes for LAN capacity. The
result can be delays and breaks in the availability of required data and functions.
If the call load increases beyond the capacity of the IR system, call handling problems are
likely to occur. A new system, or re-routing of calls, is generally required.
The IR system provides information to callers through recorded or generated speech. For
successful operation:
• Recorded speech must exist, be of acceptable quality, and be accessible to voice
response applications.
• Generated speech must be constructed properly by the Proxy Text-to-Speech feature and
the voice response application.
• Recorded speech must be transferred from a server, so that the application can play it for
the caller.
Communication between the IR system and the server or host must be adequate to deliver
speech in a timely manner.
Identifying possible causes of problems
Generally, you will work with Avaya support representatives to identify the cause of the
problem and correct it. However, you may find that some problems are easy to identify and
resolve on your own.
The following table describes common problems and suggests actions you can take to
identify them:
Problems Effects Actions
Disconnection or poor
connection of cables to the
back of the IR system
Possible effects include:
• Monitor, keyboard, or
mouse are not operating.
• Speech functions and data
resident on servers are not
accessible.
Check the cable connections.
See Checking cable
connections on page 43 for
more information.
10 Avaya IR R2.0 Troubleshooting
Contents
Inadequate or expired
feature licensing
Note: Renaming the IR
system may cause loss of
feature licensing.
Calls not terminating on the
IR system.
Poor communication or no
communication with
required servers across the
LAN
Incorrect system
administration, such as
errors in channel
assignments, server
assignments, and other
configuration information
Affected features are not
functioning, or are not
functioning as expected.
Callers hear a fast busy signal.
Possible effects include:
• Response times for speech
functions and data retrieval
are slow, interrupted, or
both.
• Speech functions and data
resident on servers are not
accessible to voice
response applications.
Degraded or non-functional
voice response services
• From web administration, go
to the Feature Licensing
screen (Configuration
Management > Feature
Licensing) to identify the
features licensed for the
system.
• Contact your Avaya support
representative if you have
renamed the IR system or
to purchase more features, if
you require them.
• From web administration, go
to Configuration
Management > System
Control.
• Stop and start the voice
system.
• Test the LAN connection.
See Checking LAN
communications on page 36
for more information.
• Work with your LAN
administrator as needed to
resolve the problem.
• Add additional proxy speech
servers or speech server
resources
• From web administration, go
to the Display Equipment
screen (Configuration
Management > Voice
Equipment > Display
Equipment) and check the
system settings.
• Make corrections as
needed.
Inadequate system
resources (memory, CPU,
disk)
Voice response application
coding errors
Poor response times, speech
breaks, load-related messages
and alarms, increased hold
times and blocking of calls
• Degraded or non-functional
voice response services
• Dropped calls
Assess the load and reduce it, if
necessary. Manage better the
performance of your system in
the future.
Contact the vendor or internal
staff who develop your
applications.
Issue 1.0 April 2006 11
Contents
Troubleshooting procedure
If a problem develops with voice response operations, follow this general procedure to
resolve it:
1. Go to the Message Log Report screen (Reports > Message Log Report) and check for
messages about events related to the problem.
Events may generate alarms. The level of the alarm (critical, major, or minor) indicates the
severity of the problem.
2. Follow repair procedures for any events related to the problem.
On the Message Log Report screen, you may display repair procedures by using the
Explain function. Explanations of messages and related repair procedures are included in
this online help as well.
3. If you cannot resolve the problem based on events and related repair procedures, check
the indications of the problem against information in Troubleshooting based on
observations on page 15 and take action based on your findings there.
4. Before contacting others for assistance, gather data on the problem:
― Alarms received
― Application involved
― Type of channel protocol in use
― Type of card
― Type of switch
― System history related to the problem
5. Contact other resources for assistance as needed. Contact your:
― Avaya support representative for problems related to IR system operations
― Application developer for problems related to voice response applications
― LAN administrator for problems with remote access that are not related to
configuration of remote resources on the IR system
― Database administrator for problems with database functions
― Host support personnel for problems with host operations
12 Avaya IR R2.0 Troubleshooting
Contents
Using IR system events
The first step in the general troubleshooting procedure is to check for messages about events
related to the problem. This topic provides more information about troubleshooting based on
events.
Events on the Avaya IR system are logged, and alarms are generated when those events
cause or might cause a problem with voice response operations.
To troubleshoot using Avaya IR system alarms and errors:
1. When a problem arises, check the Message Log Report screen (Reports > Message Log
Reports) for messages about events related to the situation.
Events include a time stamp, event ID, and brief explanatory text. See the sample event
that follows:
Mon May 12 00:15:05 2003 CDH CDH007 -- -- --- (CDH_TRASUM) trasum
failed. Reason: Could not connect to the database
2. If you find events that are relevant to the problem, view additional information on the
event.
Additional information includes priority, description, and repair procedures. You may
display additional information by using the Explain option in the Message Log Report
screen, or by going to the online Help topic for the message.
3. Follow the repair procedure for the event.
The repair procedure may provide specific instructions, direct you to contact your Avaya
support representative, or link to other topics in the online Help or to other resources.
Gathering information on a problem
The next step of the general procedure for troubleshooting is to gather information on the
problem. The topics in this section explain how to gather the information. You may do this on
Reviewing the Display Equipment screen
your own or under the direction of an Avaya support representative.
Go to the Display Equipment screen (Configuration Management > Voice Equipment >
Display Equipment) to view configuration information, such as:
• Type of card
• Type of channels
Issue 1.0 April 2006 13
Contents
• Services (voice response applications) assigned to channels
• Service state
The following table shows state descriptions and their meanings.
State Meaning
INSERV In service
MANOOS Manually out of service
FOOS Facility out of service
BROKEN Not functioning, possibly
needing replacement
Monitoring live operations
Use the sysmon command to observe voice response operations as they occur. You can see
calls coming in, digits entered by callers, and line conditions, such as off-hook.
Note:
Monitoring live operations places a heavy demand on system resources. Using
the sysmon command at times of heavy system activity might result in overload
and interference with call processing.
Checking system history
Researching the history of your IR system helps you to identify the current problem. Talk to
others and check records external to the system to find out about:
• Previous problems and support calls
• Recent changes to the system, including upgrades and repairs
• Changes to the LAN configuration in your organization
Check the Message Log Report screen (Reports > Message Log Report) for previous
intermittent problems that may indicate a pattern.
Using Sun diagnostic tests
Three types of diagnostic tests are available through Sun applications. Use the following Sun
diagnostic tests:
14 Avaya IR R2.0 Troubleshooting
Contents
• Validation Test System (VTS) to test and validate major hardware components
• OpenBoot Diagnostics system to perform root cause failure analysis on various IR
devices
• PROM Diagnostics to check system processes, such as the error rate and type for
Ethernet packets
Sun Fire V210 and V240 Servers Administration Guide explains how to run these diagnostic
tests on the Sun Fire V240 platform. The Sun Fire 280R Server Service Manual explains how
to run these diagnostic tests on the Sun Fire 280R platform. The Sun Blade 150 Service
Manual explains how to run these diagnostic tests on the Sun Blade 150 platform.
These documents are available in Avaya IR System Help (under "Print documents") or from
the Sun Web site (http://www.sun.com).
Using commands
Execute IR system administrative commands to check components and processes.
Information available through administrative commands includes:
• The allocation of resources for all devices
• Resources and space available in the database
• Feature packages installed on your IR system
• A report of all active fax jobs
Since the Solaris operating system is Solaris-based, you also can run Solaris commands that
check devices, processes, and files.
Troubleshooting based on observations
Troubleshoot based on observations when:
• You have reviewed the Message Log Report screen and cannot identify any events
related to the problem.
• The suggested repair procedure for the event does not completely resolve the problem.
• Further investigation is required, such as when you are investigating an intermittent
problem.
Issue 1.0 April 2006 15
Contents
Investigating operations problems
Problems central to voice response functions can affect business operations and may result
in missed calls and caller frustration. Most of the problems described in this section require
prompt attention. To investigate these problems, you should have a good understanding of
the Requirements for successful operations
Call-handling problems
Call handling problems include issues related to responding to and transferring voice and fax
calls. This section provides information about how to resolve various call-handling problems.
Voice system not answering
The voice system will not take calls. The voice system rings but does not answer, or the voice
system is busy.
Note:
If you depend on a host system for caller services, refer to Host interaction
problems on page 22.
on page 6.
To check on possible causes of the problem:
1. Determine whether the voice response application required for the service is running.
― If the application is a permanent process, use the Solaris ps command to list the
running processes and look for the application process.
― If the application is started on demand, the AD (application dispatch) process starts it
when a call arrives for that application.
2. If the application is not running, take any required actions to correct the operation of the
voice response application.
The application may not be installed or there may be errors in coding. For instance, the
voice response application should contain an action to answer the phone. Check with the
person responsible for development of voice response applications for more information.
3. If the voice response application is running correctly and does not contain errors, ensure
that all cards are in the in service (INSERV) state by taking one of the following actions:
― Enter display card all and press Enter.
― Go to the Display Equipment screen (Configuration Management > Voice Equipment >
Display Equipment).
16 Avaya IR R2.0 Troubleshooting
Contents
4. If cards are not in service, either try to restore them or contact your Avaya support
representative.
See Restoring cards and channels
on page 48 for procedures that may bring cards back
into service.
5. If cards are in service, go to the Channel Services screen (Voice Equipment > Voice
Services > Channel Services) and verify that required voice response applications are
assigned to the appropriate channels.
6. If Speech Recognition or Text-to-Speech are in use, make sure that those applications are
working and that servers running the applications are accessible.
7. Go to the Message Log Report screen (Reports > Message Log Report) and check for
messages indicating that the Transaction State Machine process (TSM) is respawning
due to an excessive number of channels in the system.
The message MTC017 (MTC_RESPAWN) indicates respawning of a system maintenance
process.
8. If TSM is respawning due to an excessive number of channels, reassign channels to
another Avaya IR system or contact your Avaya support representative to order more
channels.
Calls dropped
The Avaya IR system can drop calls at the initial prompt or at any other time.
Calls dropped at initial prompt
The IR system may drop calls when the initial prompt is playing if the prompt was recorded
over background noise, such as a fan or ventilation system. The background noise may be
detected as a dial tone following connection by the caller. If this happens, the call is dropped
by the IR system. To fix the problem, re-record the prompt without the background noise.
Note:
For sound quality, you should record in an environment that is free of
background noise.
All calls dropped
Take these actions when all calls are dropped:
Note:
If you depend on a host system to provide information to callers, refer to Host
interaction on page 22 problems.
1. Go the Message Log Report screen (Reports > Message Log Report) and scan it for
messages related to the trouble.
Issue 1.0 April 2006 17
Contents
Look for messages that occurred just before and at the time when calls began dropping. If
calls are handled by VoIP, look for the messages VOIP_DISABLED_CALL_PROC or
VOIP_CALL_FORCE_CLEARED.
2. Type who -rpb and press Enter to display a log of system processes.
3. Search for different time stamps on the processes.
A recent date different from most of the others may indicate that the process respawned.
4. If you find different time stamps, record the situation that caused the problem and take
steps to correct it.
Calls not transferred properly
A transfer may fail simply because the number receiving the call is busy. However, if there
are repeated problems with transfer operations, the cause may be:
• Digits are being dialed incorrectly.
• The switch does does not support transfer operations.
• There are mismatches between the anticipated number of digits in an ANI or DID pass
and the actual number received. (This situation applies to the R2MFC protocol only.)
To resolve the problem:
1. Ensure that digits are being dialed correctly:
a) Type sysmon and press Enter to observe system operations.
b) Observe transfer operations to determine if the correct digits are being dialed.
c) If the wrong digits are being dialed, make the required correction in the voice response
application.
2. If the correct digits are being dialed, verify that the transfer number is valid and that the
switch supports transfer operations.
3. If the R2MFC protocol is in use, try to match the anticipated number of digits in an ANI or
DID pass and the actual number received:
a) Type sysmon and press Enter to observe system operations.
b) Observe transfer operations to determine the number of digits passed in ANI and DID
operations.
c) Use the nms command to specify the correct number of digits.
Note:
It might not be possible to specify the correct number of digits for each call
instance.
18 Avaya IR R2.0 Troubleshooting
Contents
No DTMF tones (WINK protocol)
If voice response applications are not responding correctly to caller input, you may suspect
that DTMF tones (the tones that identify the called number) are missing. For calls handled
with the WINK start protocol, run a trace to determine if the NMS card is receiving the tones.
To set up the trace:
1. Set the following values in the cta.cfg file:
― Tracemode=1
― Tracemask=allevt
― Tracefile=cta.log
2. Stop and start the voice system.
3. Review the ctdaemon file.
The system displays trace output.
4. Check the trace output to determine whether digits are being sent.
In the trace output, the digits in parentheses for the val field identify digits sent. In the
sample trace output that follows, val entries indicate that the digits 1, 2, and 3 were sent.
(The digit 3 is not significant, and the val entries are in bold here to help you find them.)
MESG: Tue May 13 17:08:48 2003
| pid=580 tid=578 ctahd=80000001 (CTATEST) uid=0 tag=4006 sev=0
| DISPEVT: ? NCCEVN_RECEIVED_DIGIT (1c201d) (val=31) objhd=1
src=1c dst=2000 time=235a9a97 uid=0 size=0 buf=0
MESG: Tue May 13 17:08:48 2003
| pid=580 tid=578 ctahd=80000001 (CTATEST) uid=0 tag=14001
sev=0
| ? Msg:854D Ch#01 Obj:0000 Np=16 Nb=0 0032 0000 0000 0000 0000
0000 ...
MESG: Tue May 13 17:08:48 2003
| pid=580 tid=578 ctahd=80000001 (CTATEST) uid=0 tag=4006 sev=0
| DISPEVT: ? NCCEVN_RECEIVED_DIGIT (1c201d) (val=32) objhd=1
src=1c dst=2000 time=235a9b32 uid=0 size=0 buf=0
Issue 1.0 April 2006 19
Loading...