UCCX Redirect Step and Local Route Groups

[Frank den Haan]

Hello,

CUCM 9.1.2
UCCX 9.0

I have come across a situation in one of our UCCX scripts with the call redirect step where it is forwarded to a local cell phone for after hours calls. The number in the Call Redirect step is 9, followed by the 10-digit number of the cell.

While the call does redirect successfully from the UCCX script, the call always uses the local route group of the original calling party's device. So, if the call from an IP Phone to the cell is going out the gateway where the cell number is a local call, the 9 followed by the 10 digit number works fine.

If it's a site across the WAN, the call redirect to the cell fails because it's using LRG of the calling party's phone and thus it needs to be a long distance call.

I kind of thought the Service Parameter Local route group for redirected calls being set to "Local route group of last redirecting party" might have addressed this, like it did for call forward all situations, but it does not seem to be the case.

Would the recommendation be to use Call Consult Transfer instead of the Call Redirect step? This seems to work, but was wondering if there were other ways to approach it.

Thanks for your help,

Frank

[Anthony Holloway · Accepted solution]

When you use Call Consult Transfer the call should go out the LRG of the DP of the CTI Port.  Because it should look like a brand new call to CUCM.  Is that what you're seeing/wanting?  That would be TEHO for remote sites.

Alternatively, you could switch to a +E164 numbering plan and then you will not have a problem with number formats.

It wouldn't even have to be a full migration.  Just create a \+! pattern for UCCX to hit, and use SLRG.  Then, on your egress points (voice gateways, trunks, etc.) use Called Party Transformation Patterns to match upon the following (assume the local calls begin with 612 and are called via 10d):

\+1.612! = PreDot //local

\+.1! = PreDot // national

\+.! = PreDot // international

Because you're matching on +E164, it can coexist inside your dialplan today.

[Frank den Haan]

Hi Anthony,

Thanks for the reply. The Call Consult Transfer step did resolve my issue, so now the call is always coming from the local site and using the LRG of the DP of the CTI ports. I previously had it set up using the Call Redirect step in the script with 9 followed by the 10-digit number, and thus it was kind of not working when calling over the WAN from remote sites.

I should have mentioned that we recently did an CUCM / CCX upgrade. In CUCM, all call restrictions were previously done at the device level, nothing on the line. Now we have the line doing the call restrictions. So the Call Redirect step worked fine in the old environment with the 10-digit number, not so much in the new.

But I like your suggestion about +E164 even better, since we rolled that into the upgrade as well. I tried putting the full +E164 number in the script using the Call Redirect step. Works perfectly from all sites.

Thanks for your help.

Frank