UCCE - Handling wildcard DNs through Default Call Type configuration

[Jameson Gagnepain]

I recently had a need to route a wildcard DN from CUCM to UCCE. As ICM matches to specific DNs, not wildcards, I had a bit of a dilemma on my hands. The wildcard pattern I needed to route was "**71XXXX". I wasn't about to go create 10,000 new DNs in ICM to handle every possible number... so I came up with a simpler solution:

1. Create the **71XXXX CTI Route Point in CUCM. Assign control to "pguser" Application User as usual.
2. Create a Dialed Number in ICM with Dialed Number String of **71XXXX so calls will route to ICM.
3. In PG Explorer, under the Peripheral for CUCM, on the "Routing Client" tab, set a Default call type. I'll use "HandleDefaults" in this example.
4. Schedule a script for the default call type. In this example, I'll name the script "HandleDefaults".
5. In the HandleDefaults script, check if the left 4 digits of Call.DialedNumberString is "**71" and length 8. If so, requalify the call to another script. Otherwise, release the call.

While this solution is a little tricky, I feel it provides a good method for handling wildcards. The alternative (10,000 DNs in ICM in this case) is far too large to build and manage changes on.

One thing to keep in mind - using the Default Call Type does potentially reduce the utility of the Route Log Viewer. Any calls that hit the default call type because of a missing DN or Call Type mapping (in this case, any calls from CUCM without a DN) will no longer show an error in Router Log Viewer to let you know the problem. However, with having a Call Type applied to missing DNs, you can potentially create reporting in CUIC to see these errors.

[Chintan Gajjar]

Great trick Jameson.

Regards

Chintan

[Kartik Bhatia]

Great trick, I was looking for something similar.

Kartik

[Mike Cairns]

That is great advice, but Cisco should really consider adding a wildcard functionality to the product.  If you are using CTIOS you can use it in the ICM/UCCE DialedNumberPlan from configuration manager and that works, but the the minute that you dial from a hard phone it will fail.  If you extensively use CTIOS you might look at the DialedNumberPlan as well and then translate it to another number or script similar to what you are doing.  

Nice post.

[Jameson Gagnepain]

Mike,

I'm well aware of the ICM Dialed Number Plan, I often use its wildcard functionality for agent transfers.

In this specific case, I was creating a front-end for CUCM MeetMe Conferencing, providing pre-conference messaging and a sort of queuing for when the initiator hasn't arrived yet. All calls for this would be originating at a hard phone, so this seemed the best solution.

-Jameson

[thomas hagen]

Jameson, can you elaborate on how you did step 5? I'm trying to do the same thing, only match the first 5 from Call.CallingLineID but I can't get it to work. The goal is to match a specific numberseries to set queue priority.

[Jameson Gagnepain]

Thomas,

In this case, I used the CLID node. On the Calling Line ID tab, I set Case 1 Calling line ID to **71, with a Type of Prefix. On the Variable tab I chose "Use Expression" with a value of Call.DialedNumberString.

I used this method instead of an If node, as it allows my HandleDefaults script to be simpler to expand in the future for other potential wildcards.

You could also program the same thing with an If and a formula like:
left(Call.DialedNumberString,4)=="**71"

To match against the first 5 digits on Call.CallingLineID as you are trying, you could either use the CLID node as I did but set the Use Expression to Call.CallingLineID, or you can use an If node with a formula like left(Call.CallingLineID,5)=="NumbersToMatchHere" .

-Jameson

[thomas hagen]

Thanks Jameson.

It appears I was doing it right the whole time. I was trying 

left(Call.CallingLineID,5)="220863" and the CLID node with the same number and type prefix. My problem was that I based how the ANI looked like on the fact that an if node with Call.CallingLineID="22086315" was true, but the real ANI was prefixed with 0. As I corrected it both the if node and the CLID node worked. No clue why the if node that matched on 22086315 was true though.

Thanks for your help and reply!

[Jameson Gagnepain]

Thomas,

That makes total sense. Call.CallingLineID="22086315" would evaluate CallingLineID as an integer and leave off the leading 0, so it would be True.

-Jameson