I'm working through development of a generic ICM routing script that uses Service references by expression within a Route Select node, and I cannot figure out how the ICM makes a determination of which translation route to use for the service that is 'rendered' by evaluating the expression. When building the RS node, the translation route column in the configuration panel is not configurable--all you can do is mark it with an 'X'. Since I have more than one TransRoute for this peripheral (this will be a VRU-to-ACD translation route), I'm stumped about how ICM picks a TransRoute for that Service.
Also, if anyone has any suggestions about expression formatting, I'd like to hear them. The documentation on this is very scant.
you are overprovisioning, which is right, are you using VRU service arrays and enterprise services? Please check also CSCsa36827.
For this and similar questions I truly suggest you subscribe to the Dev Support Services, that group has the experience of supporting several similar scenarios for different customers.
CSCsa36827 in the Bug Toolkit does not provide any bug details.
I'm not using Service Arrays because they don't apply in this particular case--I'm moving a call from a VRU to an ACD. I can simply do the scripting with a separate routing path/branch for each ACD destination possibility from the VRU, but this will become a maintenance challenge as the number of service choices increases.
Currently, the RS node using indirect references works as it should--the expression evaluates properly and comes up with a service name--but the actual translation route selected by the ICM isn't correct. Of the two it can choose, it consistently picks the wrong one; it chooses the Xrte configured for a different peripheral (PG2 vs. PG1). The script is associated with a DN for a VRU on PG1, and the destination ACD group is also on PG1.
I'm confident I don't need developer support on this issue, because my question here specifically deals with the behavior of the RS node when using it in indirect mode. I just want to know what criteria the ICM uses when it picks the translation route to associate with the service that the expression renders in the node.
If this is more appropriate for TAC to evaluate, I can do that as well--but this seems to be a straightforward question that the scripting documentation does not address.
would you please provide a basic sample of your scenario with some generic numbers, what you have defined and which route gets selected, etc.
It is an enhancement for 7.5.1, here is the text for the Release Note:
When choosing an available target for a pre-route or post-route call between multiple
peripherals, the best target may not necessarily have enough free Translation Route routes.
If a service on "Peripheral 1" has a lower minimum expected delay than a similar
target on "Peripheral 2", the routing logic will select this target over a second peripheral target.
However, "Peripheral 1" may have exhausted the available pool of Translation Route routes. The call routing will fail and default routing will be required to complete the call request. This is not optimal. The target on Peripheral 2 would have been a better target.
To increase the Translation Route routes for all targets.
Certainly. The test scenario I am running is as follows:
1. VRU1 issues New Call request on DN 888-8888. VRU1 is on PG1.
2. ICM runs routing script, and then executes Run VRU Script node.
3. On conclusion of the Run VRU Script node, VRU1 sends additional PV and ECC values.
4. ICM then executes Route Select node.
The RS node is configured for use of Expression/indirect reference for a service at the destination ACD. For testing, I've only got one service I'm using, called DMS100.TIS.
The expression in the Service field is concatenate("DMS100."&&Call.PeripheralVariable6). The VRU sends the service name in PV6 when the VRU script ends.
The 'consider if' for that row is set to 1=1, and the 'select min value' field is set to 1. This is the only row in the node (again, just for testing purposes).
At the far end of the RS node, I've placed an X mark in the check box for Translation Route.
I have four translation routes configured on this system--two each for the Peripherals that control my VRUs. I have two PGs and three VRUs. VRUs 1 and 2 are on PG1, and VRU 3 is on PG2. The ACD is on PG1 as well.
There are two TransRoutes for each 'set' of VRUs. I have it set up this way because the apps I run on the VRUs belong to different divisions of the company, each of which pay for the actual DNs used for the TransRoutes that move the call back to the ACD--and they are very picky about who uses 'their' numbers.
In this particular test case, there are two TransRoutes that could be valid for VRU1 to use in order to reach the ACD: We'll call them TransRoute 1 and TransRoute 2.
The expression evaluates properly, and gives me the service name DMS100.TIS. When I run a Call Trace, however, the router always picks TransRoute 2, which is for the 'other' customer.
There isn't a way that I can see where a TransRoute can be explicity associated with a given destination service at a target peripheral.
In the case of the DMS100, all of the TransRoutes use the same Network Trunk Group, so if that is the criteria used by the ICM when picking a TransRoute, then it won't be helpful.
If screen shots or other info would be helpful, please advise.
Hi again tim,
In the Route Select node, please click the "Change" button, and verify that 'start with next target' is selected.
Else, all things equal (1=1), it'll always pick the first item in the selection list.
Would you please confirm my understanding that you wish to segment the calls going to the same DNIS through different VRU routes by the mean of a translation route.
I had similar scenarios in the past and the call distribution was never easy to set, usually we ended up provisioning a different route based on a formula or a value coming from a CED. Is this an available option?
The 'start with next target' is checked. I'm only using the 1=1 in the Consider If field in order to force the node to always consider that row for testing purposes.
These are very challenging to set up, and I'm working through those issues using custom formulas with varying success.
CEDs are an option, but whether I use a PV, CED or ECC as the 'variable' criteria, I still have the same problem at the RS node.
I do have this all set up with direct references for all IF statements and for the last Route Select node, and it is working correctly--I just wanted to use the indirect reference feature of the Route Select node if I could.
Ultimately, however, I'm still left with my basic question: in the Route Select node, when using indirect references for a particular destination service, how does the ICM choose the Translation Route it uses for a particular service when there are multiple Translation Routes for the peripheral to which the target service is assigned?
In the call tracer window, when it evaluates the RS node and does all of it's checking, one of the lines says: "Service
The translation route it is choosing is not for the right source peripheral--it's for a VRU on a completely different PG.
Since all I can do in the RS node is put an X in the box that says 'Translation Route,' I just want to know how the ICM is choosing it.
I can provide screen shots or other info to make this clearer if it will help.
in a perffectly balanced scenario it will always pick the first one configured if there is an available route, not sure if any of the checks you are doing would have any influence on it(lower configID).
I suspect you have an issue in holding those paths separated for the same DNIS, not sure on the business requirement side, but my take is that to avoid all this complexity it would be lot easier to split it and create different call types, that would allow even better reporting on the calls routed.
As said previously I think this is truly material for the Dev Support Services, since much of it is more on the logical side rather then on the product functionality in itself(TAC is not assisting on custom scripting).
Understood. I will pursue this issue through developer services. Thanks for your input up to this point.
We've been trying to work around this same problem for years now with no success.
The one thing that I'm not quite clear on- have you tried setting up one Trans route pool for each peripheral but with muliple labels off of each individual Trans route to represent the different routing clients?
This is what we would do if we could, then the Route Select would only have one pool to choose from. We're stuck with our own business problem though, but it has to do with their sensitivity around disaster routing. I'm not sure I understand why reporting is the problem for your business... they should be able to get accurate counts on their DNs without the need for their own Trans route pool.
We have had a standing request with Cisco for about 5 years to clarify this issue. In Version 6.6 when you you use a Dynamic Target, the only setting in the Translation Route column is "yes." I believe the system selects the TR with the lowest "SkillTargetID" but the one person at Cisco (probably the GeoTel guy who coded it) has gone missing.
Why can't you use a single TR Pool for the IVR? Multiple different Routing Clients (the post-routing PGs) can all use the same TR Pool, as long as each member (TR-Route-PeripheralTarget object) has multiple labels--one for each sending PG.
We had to maintain multiple TR pools--one for each business unit--because the default routing logic when TR timed out (1-2% of calls) could not go to a single skill. We could go to a single pool if TR time-outs became negligible but we never got those dominoes to fall...
Hope this wasn't so basic as to be worthless.
Thanks for your post. Now I know I'm not crazy.
We're using multiple pools because the actual DNs used for TRs on this installation (a DMS100) are paid for by different budget entities within the overall organization. This is hosted Centrex, so the customers pay for every DN that they use and are very particular about who uses 'their' numbers.
Plus, we wanted to be able to handle TR Timeout failures slightly differently for the different budget entities, similar to your situation (not able to fail out to a single skill).
I'm currently working with one of those budget teams to get the customer's DSC reinstated so that I can pose this as a developer question, and try to get an answer once and for all. For the short term, I scripted it the old-fashioned way.