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?
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?
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?
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.
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 - 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.
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.
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
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).
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,
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?
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 ?
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.
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 ???
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.
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
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?
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 (email@example.com)
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,
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.
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,
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.