Translation Route - which path is chosen

[rhornsby69]

I've got a very basic question....

I understand how TRs work but I'm wondering, if I have 20 translation routes in a single Route, what is the process it uses to select TR1 or TR2 or TR 3.....?

Is it as simple as call 1 gets TR1, call 2 gets TR2 etc?

[geoff]

I'm guessing this is a translation route to VRU to an IP IVR? You have a trigger and a set of ports in the call control group which make up the trans routes.

If you call the trigger many times in succession from an IP phone you will see the CTI port uses each time. It just works through them. You can see it. Now that's an artificial situation of course, because we started with a empty pool - all CTI ports equivalent. In a dynamic situation I'm sure it's doing something more intelligent - like adding a recently freed CTI port to the end of the list. Sorted by time.

I'm just musing - I actually don't know.

Any special reason for wanting to know?

Regards,

Geoff

[rhornsby69]

More for just information.  We are testing out a new site and have a large number of TRs and we ended up finding some that were provisioned incorrectly.  The question was asked and no one around here knew.  We assumed it was in order, but there is some indication that that's not the case.

[geoff]

Are these real trans routes across the PSTN?

Regards,

Geoff

[rhornsby69]

Yes

[geoff]

We are testing out a new site and have a large number of TRs and we ended up finding some that were provisioned incorrectly. 

I recall that happening at a customer of mine. They also had a large number of trans routes, about 200 PSTN numbers, if I recall correctly. They were all toll free numbers (I never understood the reasoning there, but they were getting a good rate).

We were seeing a percentage of trans routes fail, so we went through and checked all the numbers by calling them.

We did hit a couple of businesses who were delighted to hear from this particular company - because they had been getting customers looking for said company calling their number! A simple typo in the trans route DNIS.

It was hard because the 200 DNIS were all over the shop with no particular pattern. This fix reduced the failures by 0.8%.

We had another problem with the trans routes failing that took ages to track down. Again, around 0.7%.

In this case the trans route was failing because the "IVR in the cloud" (a hosted IVR) was making a trans route request through the VRU PG, and then playing a "transferring" message, which occasionally exceeded the trans route timer. These big sites with serious call volume through the Call Router are really hard to debug.

Between these two we had 1.5% trans routes failing and no one was happy about that.

I am sure other NetPro veterans have trans route stories to tell.

Regards,

Geoff

[rhornsby69]

We are set up the same way, but we are only using 20 to 30 TFNs.