Translation Route to CVP 7 from Avaya CM 3

Unanswered Question
Jun 3rd, 2010

We have ICM 7.5(2), CVP 7.0(2) and Avaya CM 3.1.2.  Calls come into CVP, which then interacts with ICM to give an IVR experience.  The calls then take-back and transfer to the Avaya.  When the agent reaches a certain point, they need to transfer the call back to CVP.  We want to use Translation Routes to do this so that the data collected in the first trip through the IVR can be passed back again.  Obviously, we do have PGs connected to both CVP and ACM.


The data passes from the first IVR trip to the ACM without issue.  The trouble is in getting it to go back.  The agent dials a VDN that does an Adjunct step, which then kicks off an ICM script.  The ICM script hits a Route Select with four Services, one for each of the CVP PIM/CallServers.  As required within these Services, I defined a Peripheral Target DNIS, chose the Network Trunk Group and defined a Routing Client + Label.  For lack of any better ideas on how to make them unique across the four Services, I set the DNIS and Label to  <RoutingClient.TollFreeNumber>.  This could be the source of the problem but I can't figure out how else to use the same TFN in the DNIS and Label fields on four different Peripheral/RoutingClients.


The Route Select also specifies a Translation Route for each of the four Services.  I set the Peripheral Target DNIS to the literal TFN and the Label as the Avaya Routing Client + VDN.  That VDN plays an announcement that evokes another take-back and transfer to send the call back to CVP.


My test calls do actually transfer back to CVP.  However, they arrive as a new call on CVP (new RouterCallKey) which means that the data in the CallVariables is lost.  I need to figure out how to configure the Services and Translation Routes such that the Route Request from CVP links the calls back together, maintains the same RouterCallKey and keeps the data in the CallVariables intact.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
marktindal Tue, 06/22/2010 - 09:25

The problem here is that it's not true TBAT because the call is pre-routed it can't be so there will still be two call legs.


I suggest as a workaround you use a global variable to manage your CV data, it'll need a little clever design but it should take less time than trawling through your TR config.


I hope this helps


Regards

MT



Mark Tindal

Engineering Manager

JAMIP

Actions

This Discussion