Blocking Inbound calls to Cisco Unified Communications Manager based on Caller ID

Blocking Inbound calls to Cisco Unified Communications Manager based on Caller ID

Introduction:

The ability to block calls based on the calling party number is a feature required by many customers to prevent unwanted calls, whether from telemarketer, malicious callers, or others, from reaching their end users. This application note will describe and illustrate how to set up call blocking using Cisco Unified Communications Manager v8.0 and later.

Audience:

This document is targeted at administrators that are familiar with call routing in the Cisco Unified Communications Manager environment. To implement this feature, the administrator must have good knowledge of the existing dialplan, call routing and call flows to be able to implement the caller ID blocking feature. The administrator must understand Partitions, Calling Search Spaces and Translation Patterns.

Call flow:

Traditionally, when calls arrive in the Cisco Unified Communications Manager environment, the call is processed based on the called party with no routing decision made on the calling party number.  Starting in Cisco Unified Communications Manager v8.0, by using familiar call routing techniques, an administrator can now match and deny a call into their system based on the calling party number as well as the called number.

In CUCM 8.0, there is a new parameter on Translation Patterns called “Route Next Hop By Calling Party Number”.   After matching an inbound Translation Pattern that has the “Route Next Hop by Calling Party Number” check box selected, CUCM will perform digit analysis on the calling party number and thus allow the administrator the ability to block the call if matched (in order for the restricted calling party feature to work, all target directory numbers must be contained in a partition reachable through a Calling Search Space. The called number cannot be in the <none> partition.)

If the calling party number does not match a Translation Pattern number to block, then CUCM will continue processing the call and route the call to the destination directory number.

Configuration:

Only a few Partitions and Calling Search Spaces are necessary to create a call blocking “Filter list” of calling numbers.  See Figure 1 above for call flow.

1)      Create two Partitions called ‘Inbound_Calls’ and ‘Filter_List’.

2)      Create two Calling Search Spaces called ‘Gateways’ and ‘To_Filter_List’.

3)      Add ‘Inbound_Calls’ partition into the ‘Gateways’ Calling Search Space.

NOTE: The ‘Gateways’ Calling Search Space must not contain any partitions that contain directory numbers, otherwise, calls will be routed directly rather than through the calling party filters.

4)      Add the ‘Filter_List’ partition to the ‘To_Filter_List’ Calling Search Space.

5)      Create a Translation Pattern ! in the ‘Inbound_Calls’ Partition. Set the Calling Search Space to ‘To_Filter_List’ and check the ‘Route Next Hop By Calling Party’.

NOTE: The ! pattern is used to match all incoming called parties in order to route the calls into the ‘Filter_List’ Partition for calling party matching.

6)      Create a Translation Pattern ! in the ‘Filter_List’ Partition. Set the Calling Search Space to route non-blocked calls to their destination.
The ! in the ‘Filter_List’ Partition is used to route any calling party number that is not specifically defined as a blocked number . The Calling Search Space routes the call back to the phone’s partition for normal call routing

7)      Some calls may arrive without caller id or a restricted caller ID. If you wish to allow calls without caller ID, there will also need to be a <none> or blank Translation Pattern. If the administrator does not define a <none> Translation Pattern, then all calls without caller id will be rejected.

8)      Using normal pattern matching, create Translation Patterns to match calling party numbers you want to block. To block all calls that have a calling party number beginning with 800, create a Translation Pattern of 800! in the Filter_List Partition. Set the Route Option to ‘Block this pattern’ with the desired reason code.

Alternatively, instead of outright rejecting a call, the administrator can configure a directory number in the ‘Called party transform Mask’ field which will allow calls to be redirected to a specific DN.   For example, an administrator can send calls to an Auto Attendant with a message indicating their call has been blocked or rejected.

9)      The last step is to assign the ‘Gateways’ Calling Search Space to any ingress gateway that will be blocking inbound calls based on calling party identification (H323, MGCP or SIP trunk).

Adding Call Blocking Based on Calling Party ID to an existing system:

Customers that already have a dialplan in place that want to add Call Blocking based on Calling Party can easily do so. When a call arrives in Communication Manager from a gateway or trunk, the call is routed based on the Calling Search Space assigned to that gateway or trunk.   Following the configuration steps above, an administrator can set up the global translate and blocked number Partitions through step 8 without affecting call processing in the system. But the last step should be done after hours or during a maintenance window because after the change to a Calling Search Space, the trunk or gateway must be reset to have the changes take effect.

Blocking “anonymous” calls over a SIP trunk:

With the rapid adoption of SIP trunks, an anonymosu caller will actually have the words “anonymous” or “unavailabe” in the From: header.  Cisco Unified Communications Manager digit analysis engine is not designed to match on non-numeric strings, so the name anonymous would be passed as a valid string.  To correctly identify and block anonymous or unavailable callers, apply the anonymous_clid.lua script to any SIP trunk that recieves call that you want to block anonymous calls.  Instructions for use are included in the script itself.