CTI Data Missing : Call Transfer to Avaya IR

[#1]

Hi all,

Setup:

ICM with Peripherals as Avaya ACD and Avaya IR

Each PG Node is Configured for ACD and IVR Separately.

Call flow:

1. The ICM Routed Call Reaches the Agent Desktop with all the necessary info in DN,ANI,CED.

2. Agent Intiates the Call Transfer by modifying the Call.Peripheralvariables values to the IVR using the Translation Route.

3. Call lands at the AVAYA IR without the CTI Data which includes the Call.Peripheralvariables values.

Now the Problem is, the IVR Application needs the CTI Data to next step of call flow.Without that, its failing the get the right Prompts.

Any Ideas or inputs to troubleshoot further.

Or If anybody has the detailed procedure for this, request you to help me.

Thanks in Advance,

Kumar

[Riccardo Bua]

Hi Kumar,

you should be using translation route and monitor the VDN performing the transfer(Configure it as an ICM Service and add it to the peripheral monitor in Configure ICM), how is the IR configured? SCI or Event feed?

Regards,

Riccardo

[#3]

Hi Riccardo,

The Translation Route is used to transfer the calls to the IR.

I need to find out which VRU Interface is used?

Can you please tell me what difference is between the two vru infterfaces ?

Thanks,

Kumar

[Riccardo Bua]

Hi Kumar,

did you define a network VRU? That would mean a service control interface, if a normal one than it would mean an event feed one.

Both should have a correlationid to match your translation route and get the data to your CTI application.

Do you see something like unknown call in OPC logs for the VRU PG?

This would mean something is going wrong on how the dialogue is set.

Are you connected to analogue or digital ports to the Avaya ACD from your IR?

If those are digitals we should be able to monitor incoming calls on those DIDs if you put them in the peripheral monitor and if the transfer gets done on a monitored VDN.

Is this a post route scenario or are you connected to a SS7 network?

If this is all ISDN PRI traffic then you should get the data being matched.

Regards,

Riccardo

[#5]

Hi Riccardo,

Thanks for you reply.

Kindly help me with bit more assistance.

Its configured as a Network VRU and uses the Event Feed.

I am not understanding the second line which you mentioned.did you mean the correlationid is the one which will match both callids of the calls and transfer the CTI-Data from one call leg to the other call leg?

I am not seeing any errors in the logs "unable to match the Callid"

My Translation Route has the VRU-Peripheral Target DNIS as 26263 and a Normal Label as 53076 for Routing Client as Avaya ACD.

Is it possible for you provide the Translation Route Format, if my above one is wrong?

So that I can compare with my Translation Route Configuration.

thanks,

Kumar

[Riccardo Bua]

Hi Kumar,

I still have trouble understanding how the IVR has been configured.

Just to clarify the complete scenario:

Translation Routing

When a VRU is the target of a translation route, the call arrives at the VRU

with a DNIS reserved for translation routing. This DNIS must be presented

to the ICM so that the arriving call can be associated with the existing call

context information. How the DNIS is presented to the ICM depends on

the interface feature being used.

Service Control Interface

When a translation-routed call arrives at the VRU, the VRU must recognize the call as being a translation route connection and send a Request Instruction message to the VRU PG. The Request Instruction

message must include whatever Correlation ID, DNIS, and/or "Called

Number" values arrived with the call. The identifying data allows the ICM

Router to associate the message with a waiting ICM Router Script.

CRI with Event Data Feed

When a translation-routed call arrives at the VRU, the VRU must issue a Delivered Event as it would for any arriving EDF call. The Delivered Event associates the VRU-assigned call ID with the new call and specifies the DNIS that arrived with the call. After recognizing the DNIS as a

translation-route DNIS, the VRU must issue a Route Request Event to obtain the data associated with the call. The Route Request Event must specify the call ID that was in the Delivered Event.

Warning: The Dialed Number in the Route Request Event must NOT

match any configured Dialed Number. For clarity we recommend that the

string "TRANSLATION_ROUTE" be used for the Dialed Number.

The ICM uses the call ID in the Route Request Event to find the DNIS that

was in the Delivered Event message, and uses that DNIS to find the call

context information associated with the call. The VRU PG delivers the

associated call context information to the VRU in a Route Select message.

CRI without EDF

When a translation-routed call arrives at the VRU, the VRU must

recognize the DNIS as a translation-route DNIS and issue a Route Request

Translation Routing 37

Event to obtain the call context information associated with the call. The

VRU must specify the call ID of the Route Request Event as a NULL ID

value (FFFFFFFF hex) and must give the DNIS value in the

“DialedNumber” field.

The ICM uses the DNIS supplied in the “DialedNumber” field of the

Route Request Event to find the call context information associated with

the call. The VRU PG delivers the associated call context information to

the VRU in a Route Select message.

Please check the VRU PG logs or VRUtrace output to confirm you receive the right info from the VRU side.

Regards,

Riccardo