07-25-2002 01:20 PM - edited 03-12-2019 08:04 PM
Has anybody seen this message in the router service? "06:17:32 ra-rtr Physical controller ARL_ACD, timed out call (Callkey 28130) on translation route AllSitesTnT2ARL1_TR, peripheral target 7485." If so, is it a problem, and if so how do I fix it...
07-26-2002 09:22 AM
Taccella,
We see this with the Nortel Peri IVR systems sometimes where the call never arrives on the DNIS expected. Do you have the Cisco 41_ACDICR_Reporting Document? If so, see section 5.3 on translation errors and timeouts. Also you can see these in the NT event log error code 351 430 on the router system.
Kelly
07-26-2002 09:26 AM
Do you have a link to that document?
07-26-2002 01:31 PM
Can't find a link, but here's a copy of some of it:
5.3.3. Translation Route Troubleshooting
Troubleshooting translation route errors is one of the more complex tasks
in troubleshooting the ICM software. This section describes how
translation routing works. It also presents some common problems
associated with translation routes and offers suggestions on how to
troubleshoot these problems.
Translation Route Overview
Sometimes you want to send additional information along with the call to a
skill target. Translation routes allow you to do that.
A translation route is a temporary destination for a call. When the ICM
software returns a translation route label to the routing client, it also sends
a message directly to the Peripheral Gateway (PG) at the targeted
peripheral. This message alerts the PG that a call will be arriving that
requires route translation. The message contains the following
information:
§ The trunk group on which the call will arrive and the DNIS value
associated with it.
§ A label to be used by the PG to determine the ultimate skill target of
the call. This is a label that the PG can interpret to find the correct
destination.
§ Instructions for further processing to be performed by the PG. This
further processing might include, for example, looking up an account
number in a database.
When the peripheral sees the call arrive on the specified trunk group and
with the specified DNIS value, it passes this information to the PG. The
PG then combines it with the information it has received from the ICM
software. It then sends the call along with this information to the skill
target specified by the label it received. At the same time, the peripheral
might, for example, send a message to a host computer that controls the
display on the agents workstation. This allows data, such as the callers
account information, to be displayed on the screen when the call arrives.
The PG coordinates communication among the network, the peripheral,
and the computer application that controls the display.
To set up a translation route, you must do the following:
§ Set up a translation route associated with the peripheral. You do not
need a separate translation route for each possible skill target at the
site, but you need at least one for each peripheral that performs
translation routing.
120 ICM Software Troubleshooting
§ Set up one or more routes and associated peripheral targets for the
translation route. Typically, all peripheral targets for a translation route
refer to the same trunk group, but with different DNIS values.
§ Set up a label for the original routing client for the call to access each
of the peripheral targets associated with the translation route.
For example, if the routing client is an interexchange carrier (IXC),
you must set up a label to the targets with the IXC. This allows the call
to be initially sent to the translation route at the peripheral.
§ For each peripheral target that you want to be able to ultimately access
via a translation route, set a label with the peripheral as the routing
client. For example, you might want to be able to send calls to the
Atlanta.Support skill group through a translation route. To do this , you
must configure a label for that skill group with the Atlanta peripheral
as the routing client. This allows the peripheral to determine the
ultimate destination for the call.
§ To display data on the agents workstation when the call arrives, you
must configure the peripheral to inform the PG which agent is
receiving the call.
The Role of Translation Routes
ICM labels are the response to a request from a routing client. The routing
client must translate the label into a targeted peripheral and DNIS, whic h
is provided to the peripheral upon call arrival. In translation routing, there
are pools of labels. The ICM software must have a unique ID in order to
determine which data goes with which call once the call arrives at the
targeted peripheral. The ICM software ensures a unique response by using
a label from the pool of labels, one after the other. Each label is returned
incrementally to the requesting routing client for each route request. Each
label represents a different DNIS on the targeted peripheral. It is this
unique DNIS that guarantees that the call will have a unique identification.
The routing client must take the label (response) and deliver the call to the
selected DNIS at the targeted peripheral. The ICM software has a built-in
relationship with the targeted DNIS via the labels association to its
peripheral target. The accuracy of this relationship is imperative, since the
ICM software uses the peripheral target DNIS to identify the call once it
arrives at its targeted peripheral.
Note: Network trunk group and trunk group, which are also associated with the
peripheral target, are not used for call identification. However, they should
be accurate for reporting purposes.
How the ICM Identifies a Specific Call
The translation route has a built-in relationship with the targeted PG
(Logical Controller). It is this association that allows the ICM software to
notify the PG that a call will be arriving on the DNIS defined by the
peripheral target used in the translation route (Figure 13).
Troubleshooting Scenarios 121
Routing
Client
ICR Central Controller
ICR Peripheral Gateway
Route Request #2
Reponse - Label #2
Call Delivery
DNIS 1234
DNIS Notification
DNIS 1234
Figure 13: DNIS Notification
The notification message sent by the Central Controller to the PG includes
the Call Data, DNIS (via the peripheral target number), and the ultimate
destination for the call (i.e., the route). The PG and Central Controller then
wait for notification that the call has arrived from the peripheral (ACD,
VRU). This notification is in the form of a route request from the
peripheral. Failure to receive this request will cause the PG and CallRouter
to timeout the translation route.
If the ICM software receives the post-route request from the peripheral,
then it will direct the peripheral to deliver the call to a destination via the
label associated with the route. Keep in mind that a label is the only form
of a response that the ICM software provides.
In summary the ICM translation route has four tasks:
§ Provide a unique response to a requesting routing client.
§ Notify the targeted PG that a call will arrive on a specific DNIS.
§ Verify that the call has arrived by handling the post-route request from
the peripheral.
§ Provide the call data and route to the peripheral.
5.3.4. Common Translation Route Errors
The following sections describe the most common errors that occur with
translation routes: time outs, routing plan errors, and aborts.
Translation Route Time out
Time outs are the most common of translation route errors. Simply, this
error signifies that the ICM software did not receive the Post-Route
request from the targeted peripheral. It is possible to have legitimate time
outs since callers may disconnect before the call is delivered to the
targeted peripheral. There are other issues that can exist. The cause of the
problems can become quite complex and can involve many more platforms
than just the ICM software. The following are common problems that can
produce time out errors.
Troubleshooting Scenarios 125
Routing Plan Errors
All routing clients receive ICM labels as a response to their route request.
This label must represent to the routing client the same DNIS termination
that is referenced in the labels association with its peripheral target.
In Pre-Routing/Translation Route applications, the networks routing plan
must interpret the ICM label into a call center ACD location and DNIS.
The DNIS that is provided to the ACD must match the ICM DNIS
represented in the ICM configuration for the peripheral target.
In Post-Routing/Translation Route applications, this label may represent a
routing clients call treatment. This treatment may include a transfer of the
call to a local DNIS that will in turn transfer the call to the remote DNIS at
the targeted peripheral.
It is imperative that the routing plan:
§ Is identical to the configuration in the ICM translation route
configuration.
§ Delivers the call in a timely manner.
Targeted Peripheral Call Treatment
The peripheral targeted for the translation route has three basic
responsibilities:
§ Produce the Call Delivery event of the call arriving on the targeted
translation route DNIS.
§ Make a route request to the ICM software. This route request must
include providing the DNIS in the expected variable.
See also: See the ACD or System Manager Supplement for each peripheral for more
information.
§ Handle the route selected by the ICM software. The call will need to
be moved to the location indicated via the ICM label contained in the
route.
The ICM PG processes running on the targeted peripheral contains the
clues necessary to determine why the transla tion route timed out. Common
issues that occur on the peripheral that can cause a timeout are:
§ Call treatment of the peripheral changed or moved the call to a
different DNIS.
§ Call treatment failed to produce the route request to the peripherals
PG.
§ Route request failed to identify the DNIS in the expected variable for
the translation route.
§ Peripheral fails to honor the route response from the PG.
§ Call disconnects during the processing of the peripherals route
request; peripheral fails to send disconnect message.
See also: Refer to the section, Translation Route Abort, for more information.
126 ICM Software Troubleshooting
Latency of Pre-Route Message
A Call Delivery event occurring before the pre-route message to the
targeted peripheral will time out as well. This is typically caused by
network latency.
See also: Refer to the Cisco ICM Software Installation Guide and the Cisco ICM
Software Pre-installation Planning: Network and Site Requirements
Guide for more information on network latency requirements.
Translation Route Abort
Translation route aborts can also be a natural occurrence, but the regularity
should be much less than that of the time outs. Abandoned calls also cause
the abort. However, the abandon call occurs while the call still resides with
the routing client. The translation route abort would not occur in a Pre-
Routing scenario since there is no event feed from the IXC (Network) that
a call has disconnected. It does occur in instances where the routing client
is a peripheral, in a post-route translation route.
Since the ICM software relies on event messaging from the various
peripherals, it is important to understand that it is the event message that
spawns the call termination. This causes the ICM system to abort the
translation route. It does not mean that the call has necessarily ended, but
rather the event is raised and sent to the ICM system. Peripherals that are
implemented in accordance to ICM software specifications must correctly
implement the call flow messaging to ensure accurate translation routing
and subsequent log messages.
5.3.5. Translation Route Implementation Testing Strategy
Ø To test the Routing Client:
1. Create a message for each DNIS in the peripherals DNIS pool. The
message should simply identify the DNIS called (for example, DNIS
1234).
2. Write an ICM script that returns all the Labels in the translation route.
3. Associate your own phone number as part of the Call Type in the ICM
software. This will allow you to use a production 800 number for
testing purposes.
4. Call the production number. Verify that the DNIS in the ICM
peripheral target matches the DNIS in the peripherals message.
5. Note any specific DNIS failures to compare against routing clients
routing plan.
Targeted Peripheral Call Treatment
Similar to the routing client, the targeted peripheral will invoke a routing
plan or call treatment. The first call treatment must be a route request to
the ICM software. The pool of DNISs will point to this one call treatment.
Troubleshooting Scenarios 127
Ø To check the ICM translation route configuration:
1. Modify the test scripting to now include skill targets with translation
and route.
2. Use the Check Routes tool to validate the translation route and route
configuration.
3. Use Call tracer to verify the outcome of the simulated route request to
the CallRouter. This step is necessary to verify that the database and
CallRouter are synchronized.
Ø To test the targeted peripheral call treatment:
1. Point the peripherals DNIS pool to the posting routing call treatment.
2. Call again to test all the DNIS calls treatment and post route treatment
and to use each service incrementally by route request.
3. Note failures to verify peripheral post-route call treatment.
4. Load testing of translation routing is recommended. This is a
necessary step since it is possible for peripheral processes to become
loaded down so that call and data movements are affected.
5.3.6. Troubleshooting Translation Routes
Ø To troubleshoot a translation route:
Research the following:
§ Determine the type of ICM translation route error, since it will affect
the troubleshooting approach. You can try to find the error using the
Monitor ICM Event Viewer and the Router Log Viewer.
§ Make sure that the error is not an ICM configuration problem. Use the
Check Routes and Call Tracer tools. Also check the Route
Associations within ICM Configuration Manager. An error in any of
these applications means that the translation route will not complete
and must be fixed.
§ Know the abandon rate of your callers as it applies to the translation
route applications. It is normal to have a certain percentage of time
outs. Your translation route time out percentage should fall within that
number.
§ Know the average time of call movement during your busy hour.
Particularly of Post-Route Translation route applications. Look to the
peripheral provider for report data and testing methods. The Cisco
Technical Assistance Center (TAC) will ask for this information and
the method used to gather the information.
§ Determine if the error is specific to a translation route, a translation
route DNIS, a particular routing client, or a peripheral. Determine if
the failures are consistent.
§ Test the translation route in a controlled environment. If possible test
the translation route using load testing. This will help particularly in
the case of Post-Route translation routing if routing clients and
128 ICM Software Troubleshooting
peripherals are moving calls within the time-out parameters of the
ICM software.
§ If you have identified a problem, test and review the routing clients
routing plan and/or the peripherals call treatment.
§ Confirm call arrival numbers on the supporting routing client and
peripheral reporting. If possible have the peripheral supply the caller
ANI (CLID). This information is helpful if the matter is escalated to
the Customer Support Center. Speak with your peripheral vendor if
you are unsure if ANI can be provided.
Information to provide to the Cisco Technical Assistance Center (TAC):
§ General information gathered by your research into the translation
route problem. (See the bulleted items earlier in this section.)
§ Error type (time out, aborts, etc.) Check the Router Log Viewer.
§ Translation route that is failing and the logical controller (PG)
involved.
§ Provide the DNIS and Network Target ID associated with the failing
route. This information is located in the Peripheral Target table , which
can be viewed through ICM Configuration Manager.
§ Provide the scripts and versions using the translation routes.
§ If possible, have the peripheral supply the ANI (CLID) in its event
messaging.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide