Translation Route to VRU

[honan]

Can anyone help with this?

We are looking to Translation Route calls into premise based VRUs.

From the VRU interface spec, I assume the Call routing Interface, rather than the Service Control Interface has to be used? Is this right?

According to the VRU i/f spec, the VRU sends a Route Request Event message to the ICM, which responds with a Route Select Message. In the Route Select message the Label field specifies the destination to which the call should be directed. Now the destinatiion could be an application on the IVR (this is what we want in this case).

Question is, how do we specify that Label? In the ICM Script Editor guide, it shows a script, using a Translation Route to VRU node, followed by a Run VRU script Node. Is the Run VRU Script node used in this case to specify the Label in the Route Select message? I am not sure, because normally, when using the Service Control Interface, the Run VRU Script node specifies the Script ID in Run Script Request, where as the field in Route Select is "Label". Or should a Label node be used - but that is not what is shown in the Script Editor guide?

Also, the VRU spec implies that after the instructions specified in the Route Select Message have been carried out by the IVR, the call ends, and the VRU sends a Route End message to the ICM. Is there any way to contine the dialogue, returning control of the call back to the ICM, so that it can either specify another VRU script to be run, or onward route the call?

[platkeet]

The way to use this feature of the ICM depends on what you are trying to accomplish. Typically, an Xrte to VRU would only be used if you have a peripheral that needs a route response, but additional information is needed about the caller...and you can only get this information by executing a VRU application.

As a counterpoint example, if you programmed an adjunct route step from a TDM switch, and queried the ICM for a route response, you could use a Run VRU Script node...but, you would be unable to take any information that the VRU collected and "stuff it" into any ICM peripheral variables. This is the normal use of the Xrte to VRU step.

The label returned by a Xrte to VRU step to the requesting peripheral will just be a DNIS value.

I haven't seen this step used with the VRU as the Route Requestor. Perhaps it would be valuable for the forum if you could explain the ultimate goal of your programming in this case?

[honan]

Thanks.

We want to use Translation Route to VRU so that we can control which VRU port the call is sent to. (The other method we have used, Send to VRU does not allow you to choose the VRU Label, rather the Default VRU Label for the ICM is used).

I now think I understand how to specify the Label - the call is initially sent to the Translation Route, the VRU then queries the PG which provides the Label that was set up for the Route.

However what I do not now undertand is how to specify what VRU Script the VRU should run (as shown in Script Editor Guide). The reason I do n't understand this, is I would assume the VRU Service Control Interface would then be used to specify this (Request Instructions from VRU to ICM, followed by Run Script Request from ICM, followed by Run Script Result from VRU etc),however the VRU Interface spec states that the Call Routing Interface and the Service Control Interface are incompatible.If one is enabled, the PG will discable the other. That being the case, what mechansim is used to telll the VRU what VRU Script to play?

Or have I got it wrong and we should n't be using the Call Routing Interface for the Translation Route?

Andrew

[platkeet]

I'd like to check one thing with you: are the premise-based VRUs you mention in your posting IP-IVRs or TDM VRUs? I've found that the Xrte to VRU node won't work on a Type 3 VRU, which the IP-IVR is.

[honan]

They are type 2, TDM VRUs.

I believe I now know the answer to part of my original question: the call is delivered intially to the Label set up for the Tranlation route. This Label is used as the DNIS value that the VRU, PG and ICM use to track the call. The PG then provides the Label that was set up for the Route and the VRU sends the call to the "service" specified by this Label.

The remaining thing I do not understand is the actual messaging between the ICM and the VRU. I have posted another entry about this entitled "VRU Interface: Calling Routing Interface versus Event Data Feed". In summary I think I need to use the Route Request, Route Select and Route End messages for the translation routing part and then swap to the Service Control interface to invoke VRU Scripts. These messages are specified as part of the Calling Routing Interface, which is incompatible with the Service Control Interface. They are shown later (fig 12) to be in the Event Data Feed, which can be used with the SCI i/f.

Confusing or what?

Andrew

[wiwebb]

Andrew - let me back you up here. I think there may be a way to accomplish what you want without using the interface messaging change.

Ultimately, what is the call flow and what are you looking to do with the IVR? If calls are being presented to the IVR first from the PSTN, then you can't use Type 2. You probably need to use Type 6. This still allows you to use the SCI, it just changes the scripting. You can still have ICM run your IVR Scripts.

In order to use Translation Routing and control IVR scripting, you need to use Type 2 with SCI. This just means that the call needs to be presented to ICM first from the PSTN or post-routed from an ACD Peripheral. From there it can be (pre or post) Translation Routed to the IVR where ICM can control the IVR script. The benefit of using Translation Routing is complete call tracking, as you mentioned. Once call treatment in the IVR is complete, you can actually Translation Route the call back to the ACD to deliver to an Agent, all the while maintaining the data collected in the IVR.

- Bill

[wiwebb]

I should probably clarify that Translation Routing depends on the post routing capability of the Peripheral - ACD or IVR...

- Bill

[honan]

Ok understand that. Re your previous message - ok had n't considered type 6. Let me back up a bit...what I really want to do is be able to control which out of a number of VRUs the call is sent to. I also want to be able to use the ICM to control the call and specify what the VRU should do with it. I only suggested Translation Routing as you can't do this using Send to VRU. My understanding of "Translation Route to VRU" is that the call does not come into the VRU directly from the PSTN, but under the control of the ICM.

Another thing, we are using the Energis INAP NIC. We use Send to VRU for our network VRUs, which use Establish Temporary Connection, rather than (INAP) Connect to send the call to the VRU following Send to VRU. I had been assuming that Translation Route to VRU uses INAP Connect,not ETC (I would actually prefer it to be ETC). Any comments on that?

I also understand that in a given CICM instance we won't be able to use both network and CPE based VRUs.

Anyway, if there is another / simpler way of doing this, I would love to know about it.

Thanks.

Andrew

[mark.scott2]

Hi

I was wondering if you can help ?

We currently have a similar problem, but I am recieving the error "No Peripheral Target available for route 'Route' with Routing Client"

I have configured the script to send to a Service Skilled Target associated to the Route and Transroute.

How do you configure a Service to a Translation Route ?

Any assistance would be greatly apprieciated

Thanks

Mark.

[wiwebb]

Let me answer Andrew's last question first, then see if I can offer some help to you, Mark.

As far as using the Send to VRU and Run VRU Script nodes, I think there is no easy way to do much intelligent selection of the VRUs. I could be wrong, but I can't think of an easy way to do it. If all of your VRU Peripherals roll up under 1 Network VRU, then you will at least get "round robin" selection.

However, another option is to use Translation Routing from the network (NIC). It works in a similar fashion, and the Translation Route Wizard can guide you through it quite easily. You will need to create a Trans Route for each IVR Peripheral, and the DNIS pool for the TR will be the range of DNs that calls can arrive on to go to the IVR. With this configuration, you can now use Type 2 NVRU and use the Translation Route to VRU node which gives you the opportunity to intelligently select the VRU to send to. For example, the "Consider If" portion can use metrics like "Peripheral.Online=1&&Peripheral.Status<2&&TrunkGroup.TrunksIdle>0. Then you can use the "Select" column to select the VRU with the maximum value of TrunkGroup.TrunksIdle or whatever else you would like.

Mark, as to your problem - did you use the Translation Route Wizard to create your Trans Route? If not, I would run through it, as it not only creates many objects and associations for you, but it will also expose any missed configuration along the way (meaning that it doesn't create everything for you, but it will be obvious while running through the Wizard if anything has been missed).

- Bill

[mark.scott2]

Hi Bill,

Thanks for the prompt response.

As advised I have now used the Translation Route Wizard and I can now pre-route calls to the IVR, THANK YOU !

Unfortunately I am struggling with post-routing the calls from the IVR to the PG, I recieve a response from the VRU via a route request (Event ID:41) but how do I map this to a post-routing script ??????

Thanks again for your assistance,

Regards

Mark.

[wiwebb]

Ok - tell me a little more about your overall call flow. So you are now Pre-Routing to the IVR (are we talking about a Cisco IP-IVR, or is it something else?), presumably to collect data and then you are trying to do a Post-Route. What is the purpose of this Post-Route? Are you using this for Agent selection?

- Bill

[mark.scott2]

Hi Bill,

We will be initially routing customers to a N-IVR offering them the option to pay their bill. Once the customer selects this option we route them to a Sytelect IVR (Using the TransRoute process) in which an application runs for the customer to pay via a credit card.

Should the customer require to speak to an agent they will press '0' and then the Syntellect IVR will post-route them back to ICM so we can direct them to an agent via a label.

I just don't know how to route the customer back into ICM

Any Ideas ?

Thanks again

Mark

[wiwebb]

Sorry for the delay - I had a nice long post written up and it failed to submit. So let's try again!...

So, this is what I expected, as it is a fairly common scenario. There are 2 factors to be considered here:

The first, and again I'm assuming you are using the Service Control Interface and the "Translation Route to VRU" node followed by a "Run VRU Script" node. In this case, remember that ICM is still in active dialog with the Syntellect. What this means is that when the "pay bill" application has completed or been interrupted (in the IVR's perspective) and the caller is requesting to speak with an agent (by pressing "1", for example), the Syntellect should be sending the GED-125 message that the script has completed. At that point, the ICM script simply continues off the "Success" leg of the "Run VRU Script" node. Now you have what you need - the ability to select an agent or whatever you wish, without the need for an explicit Post-Route request.

The second factor, though, is how to now move the call to an agent, which I'm also assuming is connected to a PBX/ACD that may or may not be the one that the Syntellect is connected to. If there is also a PG connected to the ACD, then all that needs to be returned to the Syntellect in that second piece of the dialog is a Label. This must be a defined Label in ICM for the Syntellect Peripheral's Routing Client. The string for this Label must be something that the Syntellect can interpret to physically move the call to an agent. This is all that is needed if call context and/or cradle-to-grave call tracking is not a concern. (That's a loaded statement, eh?)

If you need call tracking and also CTI data if you are looking to provide any sort of screen pop through some CTI application (ours or not), then you need to perform another Translation Route, but this time with the Syntellect IVR as the originating Routing Client. This will allow ICM to track the call as it moves from the IVR Routing Client to the ACD Routing Client, just as you did with the "Pre-Route".

Hopefully that makes some sense - let me know if it doesn't and I can try to clarify.

- Bill

[mark.scott2]

Hi Bill,

Thanks again for your valued input.

We are actually using the 'Event Feed Interface' so therefore we are not using the "Translation Route to VRU" node but a service preceeded by 'set' ECC Variables so that the PG can inform the Syntellect VRU of the CED and ANI Customer Zone info etc ..

When a customer presses '0' he\she would want to be transfered to an agent in which the VRU would pass the ECC Variables back to the PG, but I only intend to send them to a label within ICM v 4.6.2 affiliated to an ACD but with no PG attached as yet (in which you were correct)

So from what you advise do I have to ask Syntellect to define the String for e.g. a DN= Value sent from the VRU to the PG, create the same DN=Value as a DN on the PG routing client and create a call type and a post-routing script ???

Thanks again

Mark.