Translation Route Timeout

[tacella]

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...

[kblack]

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

[tacella]

Do you have a link to that document?

[bpasqual]

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 agent’s workstation. This allows data, such as the caller’s

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 agent’s 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 label’s 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 network’s 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 client’s 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 peripheral’s

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 peripheral’s 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 peripheral’s 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 peripheral’s message.

5. Note any specific DNIS failures to compare against routing client’s

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 DNIS’s 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 peripheral’s 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 client’s

routing plan and/or the peripheral’s 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.