cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2273
Views
0
Helpful
23
Replies

Translation Route to VRU

honan
Level 1
Level 1

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?

23 Replies 23

Good - we're getting down to details!

Unfortunately I don't have much experience with the message set for Event Feed GED-125, but essentially your Syntellect script/application would need to respond to the caller-entered "0" by performing a Request Instruction or Adjunct Route Request, which would initiate a Post-Route to ICM. This message would need to contain some DN string (even if it is just the "0", but it must be unique for the IVR Routing Client) so that ICM could look up that DN and match it to a Call Type, run a script and return a Label. What you need to define in ICM for that Label is a string that the Syntellect can understand. If it is as simple as digits, or if it requires a '*', etc. That's about it.

Since you don't have a PG connected to the destination ACD, your reports will only tell you how many calls opted out of the bill pay application to speak to an agent.

- Bill

- Bill

Bill,

Once again thanks for the feedback I managed to ask the engineer to reply a VRU->PG: Route Request Event (41) with Dialed Number: 9999

I created a Dialed Number 9999 associated to the PG routing client created a call type which now runs a script, I did have to cycle the services for it to work, but it does work !

However so near yet so far ....

Now it pre and post routes but when it runs the post routing script I get the following in the rtr log:

"ra-rtr Label node had no label valid for routing client 'routing client'(ID 5001), dialled number 'routing client'.9999 (ID 6040)"

And the call simply clears down ... ? The VRU Trace shows a Route End and Call Cleared event.

Any further thoughts ?

Once again thanks for your assistance

Mark.

Based on the error message, it looks like your ICM routing script encountered a Label node, but the Label specified was not valid for the VRU Routing Client.

Did you create an explicit Label for the VRU Routing Client, or are you trying to use a Dynamic Label?

- Bill

- Bill

Hi Bill,

I created a script to test with just a start node to a label node and my DDI as the label which is configured from the PG routing client.

What am i doing wrong ?

Just a thought, then maybe we should take this to direct email if this isn't the fix.

In PG Explorer (assuming you're on ICM 4.6.x or greater), on the Routing Client tab for the VRU PG, is the "Use DN/Label map" checked? If it is, uncheck it - this might be the issue.

If not, let's take this off the forum and we can work it out through email.

- Bill (bwebb@cisco.com)

- Bill

Hi Bill,

Just to clarify, The label is configured as a configured label but in order to re-route the call back to an agent I believed that I need to send it to a label affiliated to the NIC routing client ? And not the PG as it should know where to route the call,

Mark

Ahh, that's the source of the error. The Label returned for this Route Request must be a Label configured for the VRU PG Routing Client. The NIC is out of the picture at this point, so the Label returned to the VRU PG must tell the VRU how to deliver the call.

Can the Syntellect perform a transfer to the DNIS you're trying to reach with the NIC Label? In other words, the NIC Label's label string may contain other digits like Network Trunk Group to send it over the PSTN, but ultimately it is hitting a DNIS on the ACD. If the Syntellect can transfer a caller to the same DNIS, then that's what you would need to define as the string for the Label.

Hopefully that makes sense...? Basically, you need to tell the VRU how to move the call where you want it, because the NIC no longer has call control.

- Bill

- Bill

Hi Bill,

Ideally what we need to do is re-route the call back into ICM somehow and I thought we could do this by utilising Network Take Back and Transfer ?

Is our only option to for the Syntellect to perform a transfer to the DNIS ? If so I'll chase this with Syntellect,

Thanks

Mark.

Here's where I'd use the old ICM mantra of "we don't touch the call" (well, at least we didn't before IPCC!!)...

Seriously, though - to do a TNT operation, you would need to go back out to the network (PSTN) itself. ICM can provide an intelligent routing decision, but it relies on the Routing Client's ability to carry out the orders.

That's the reason for the mantra. In the Pre-Route, the NIC (PSTN) sends a request, ICM returns a response (Label). Even with the Translation Route, the directions that the Router sends to the PG are just a response to the expected Route Request from the VRU PG. So the PSTN sets up the call to the terminating trunk that connects to the Syntellect, and in turn it performs the Route Request. That Label that the PG returns gets us to the VRU application. In the Post-Route, we are in the same position - the VRU has issued another Route Request asking what to do with an active call. That call is still terminated at the Syntellect (or connected trunk), so ICM is expecting that the VRU itself has the capability to move the call to another destination.

For a network TNT, the ICM could still issue the command, in the sense that the Label returned could be "*8####", with the "*8" meaning initiate TNT with the carrier and the # signs representing a DNIS to place the call on. But the Routing Client (VRU) would still need this "Place Call" or transfer ability.

- Bill

- Bill