Calling Party Blocking for Cisco Unified Communications Manager

Regardless of the vendor, when we discuss call routing in a telephony platform we’re almost always focused on the destination of the call. Similar to how the postal service operates, when the system is delivering the call or message, we are rarely focused on who the originator is. Keeping that in mind, it doesn’t take much imagination to come up with a few scenarios where it may be beneficial to block specific numbers, or ranges of numbers from reaching your end users.

CDW offers a wide range of collaboration solutions. See how we can help you.

In this blog post, I’ll show you how to implement a check on the calling party number (CPN) in a Cisco voice solution and keep those pesky spam calls at bay.

In order to illustrate the logic, let’s define some key components and run through a few examples.

Key Components Unique to Call Party Blocking Solution

• \+! Translation Pattern: Matches any call that begins with a +. This is used in our example to match all inbound calls and flip the routing logic to calling party number and again in a different capacity to match any digit string not explicitly defined.
• Blank Translation Pattern: Matches any call that does not have calling party number information. Without this pattern, if a call comes in with no CPN, the call will fail to route correctly.
• System Inbound Calling Block Partition: Optional, but it can be added in order to provide the flexibility to block on a systemwide scale.
• Site GW Inbound Calling Allow Partition: Blocks at a sitewide scale and allows calls from all numbers not explicitly defined.

Example 1 of Call Party Blocking – Check and Allow

Step 1: Call arrives inbound to Cisco Unified Communications Manager (CUCM) from the gateway with CPN +16515553333. The gateway has the site “GW Inbound Calling Check” calling search space (CSS) applied. This CSS contains the “Site GW Inbound Calling Check” partition which contains our \+! translation pattern that matches any dialed number, tells the system to make its next routing decision based on the CPN, and changes the CSS to “Site GW Inbound Calling Block.”

Step 2: The call is processed through the “Site GW Inbound Calling Block” CSS and searches the “System Inbound Calling Block” and “Site GW Inbound Calling Block” partitions for the most specific match. Since our CPN is +16515553333 and we do not have an explicit pattern built for this number, the system matches our \+! translation pattern in the site-specific partition. This translation then changes the CSS to what would normally be applied as the gateway inbound CSS, “Site GW Inbound,” and the call proceeds as normal.

Step 3: The call is delivered to the originally dialed directory number.

Call Party Blocking ― Check and Allow

Example 2 of Call Party Blocking – Check and Block

Step 1: Call arrives inbound to CUCM from the gateway with CPN +16515552222. The gateway has the “Site GW Inbound Calling Check” CSS applied. This CSS contains the “Site GW Inbound Calling Check” partition which contains our \+! translation pattern that matches any dialed number, tells the system to make its next routing decision based on the CPN, and changes the CSS to “Site GW Inbound Calling Block.”

Step 2: The call is processed through the “Site GW Inbound Calling Block” CSS and searches the “System Inbound Calling Block” and “Site GW Inbound Calling Block” partitions for the most specific match. Since our CPN is +16515552222 and we have an explicit pattern built for this number, we follow the routing logic of the translation pattern.

Step 3: The call is rejected due to the matched translation pattern route option being set to “Block this pattern” and that’s as far as the caller is logically permitted into the system.

Call Party Blocking ― Check and Block

Additional Considerations and Moving Forward

There are a number of special circumstances that may require additional configuration and planning such as:

• Anonymous calls: Handling calls with a caller ID in the form of a string such as “Anonymous.” This requires a SIP Normalization (LUA) script to be applied to the SIP trunk between CUCM and the ingress gateway.
• Implementation in a contact center environment: This requires reachability of any computer telephony integration (CTI) route points or route ports via the CSS of the gateway.

Of course, every environment is different and there may be other considerations that are outside the scope of this introductory post. I hope this explanation and examples demonstrate the power and flexibility of a well-thought-out dial plan and how you can use it to your advantage to provide a better experience for your users. For additional information and implementation please contact your CDW team.