Showing results for 
Search instead for 
Did you mean: 
Walkthrough Wednesdays

Blocking Calls Based on Calling Party ID



Application Note:

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



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.



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.



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.  If the Directory Numbers are +E.164, you will also need to create a /+! translation pattern in order to reach the called directory number. 
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.




      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 anonymous caller will actually have the words "anonymous", "restricted" or "unavailable" in the different From: headers (PPI, PAI, RPID or FROM).  Cisco Unified Communications Manager digit analysis engine is not designed to match on non-numeric strings (see note below),  so the name anonymous is not a valid string.  To correctly identify and block anonymous or unavailable callers, apply the SIPTrunkAnonymousCalls.lua.txt script to any SIP trunk that receives call that you want to allow or block anonymous calls.  Instructions for use are included in the script itself.
NOTE: In UCM 9.0, digit analysis was enhanced to support URI dialing, so string based dialing is supported UCM, but as an administrator, you cannot define a string/uri as a translation pattern.  Since this configuration relies on translation patterns to match dialing stings to allow or block a call, anonymous calls cannot be handled like standards numbers.

08-17-2017: The LUA script has been updated to restore the original from header on response messages to the SP/CUBE.  Please see the notes section of the script for details.

06-05-2018: Anyone that is using the v2 version of the LUA script needs to replace their script with the v5 version.  The replacement logic used global variables and not context specific variables.  This may cause calls to fail when operating under load.  The v5 script eliminates this issue.

03-25-2019: The original v5 of the LUA script had a memory leak which would cause the script to run out of memory.  The leak has been identified and correct.  The v5a of the script does not have the leak.


Additional Guidance for Contact Center Integration and ILS\GDRP:

Contact Center: If the post destination of an inbound call is a CTI Route Point or a CTI Route Port, there is a call processing caveat that will need to be taken into account.  When implementing call blocking, the ingress gateways will change their calling search space to direct all calls to the partition that will trigger filtering.  If the destination after filtering is a CTI Route Point or CTI Route Port (typically used by Contact Center applications), the call processing must take into account redirecting behavior of the CTI Route Points and CTI Route Ports.  By default, when CTI devices issue a call redirect, CUCM will use the calling party device’s calling search space to find the target port number.   To use call filtering with contact center, the calling search space on the inbound gateway will need to include the partition of the CTI Route Ports.  For additional details on this call processing caveat, please review the release note for CSCso91760 (CCO login required).

ILS\GDPR with Session Manager Edition: If your deployment is blocking calls in a SME and the called number has been learned through ILS\GDPR, then the inbound SIP Trunk’s calling search space must include the partition that has the SIP Route string for routing an ILS/GDPR call.  For example, if the inbound called party is and is not blocked in the filter partition, then the resolved destination that has been learned by ILS\GDPR must be routeable from the SIP Trunk.   Meaning, if resolves to on the SME, then the inbound SIP trunk must have access to the partition for route string for *



First and foremost I can't thank you enough for all of the help you provided working through this. The change you mention works like a charm. One thing I did have to work through was that our SBC's are Acme Packet 3820s and they didn't like that we were changing the header from anonymous to null (or empty). This was causing them to continuously send invites as the SBCs thought that the call was lost. What I found out is that if I changed it to an actual E.164 number it worked fine. It didn't have to be a dialable number, it just had to be a valid E.164 number.

In essence, the script was modified from

replacementNumber = "sip\:”


replacementNumber = "sip\:+1234567890”


This works perfectly and presents an incoming call as follows:




Again, thanks for all of your help and hard work you put into this.



George Price

Sr. Telecom Engineer

Terry Cheema

Nice Document Dan +5



hello dakeller


i m running 8.6.2-25900-8 cucm manager cluster

all my mgcp gateway and sip trunks incoming calls configured with "Inbound Css"  with filter

to block/allow/Add 9 prefix and more.

i  facing the issue with 'anonymous'  calls that the cucm manager droped and i m not sure what the action plan here


please advise a.s.a.p




Cisco Employee


First off, is the problem with SIP trunks only or do both MGCP and SIP trunks have the same issue?  If both, then it's probably a config issue.   But if it's only SIP trunk, then you may have a situation where the anonymous message from the carrier is not what the script is looking for.  

I will help you out.  I need you to send me detailed info on the call flow and the SDI trace files from the primary node the trunk is registered to.  Also, if you are using the LUA script for a SIP trunk, please turn on tracing for the script (directions are in the script itself).  

Once collected, send the information to and I will get back to you with an answer.


Dan Keller

Technical Marketing Engineer

Kaushik Ray

HI I used this, works brilliantly absolutely.


On CUCM 9 there is an option called "Reject Anonymous Calls" is there any difference as to what these two procedures achieve?

Community Member

Thanks for the document.

FYI - In CUCM version 11, you will no longer be able to start the translation pattern with '!'.

Instead I used 'X!' which worked for me.


Cisco Employee

I have a UCM 11.0(1) that I have tested this on and I have no issue adding a ! as the xlate pattern.  Can you tell me the exact version you are testing on.  Also, UCM does have some restrictions on putting generic patterns into the <none> partition.  

I have successfully added a ! in both the <none> and the filter partition on my (FCS) UCM in the lab.


Dan Keller

Technical Marketing Engineer

Community Member

In our version "System version:", when you try to add a TP; you get the following pop-up: Translation Pattern cannot begin with .!@-+?

Even when you try to update an existing ! TP, you get the same message.

Cisco Employee

Let me look into this....thanks for the heads up.


Dan Keller

Technical Marketing Engineer

Cisco Employee

Can you try using \! and check if that works?



Community Member

I am able to create the \! TP. I will test it tonight to see if it will also work.



Cisco Employee

There was a change made in the -10 version that is causing this. Need to verify with the team that did the change why ! was included in the exclusion list for translation patterns.  

The change I found eliminated the values in the error message you pointed out.  I agree that exclusion of all the values except !.  

Thanks for bringing this up and I will update this posting when I get some resolution to the issue.


Dan Keller

Technical Marketing Engineer

Kaushik Ray

Apologies to ask the question again, but can anyone advise if there is a difference as to what this procedure and the Reject Anonymous Calls under each Phone DN achieve?



Per the title of the document, this procedure enables you to block calls based on Calling Party ID.  The fact that it blocks anonymous calls is a side effect.  I can't attest to the option you speak of since I've never used it, but if you have an annoying sales call or harassing caller, you can use this procedure to add a translation pattern to specifically block them from calling your organization.

Cisco Employee

I need to review the details of the 'reject anonymous calls' feature.  From what I recall, it was very limited in what it could block, therefore, not many customers have used it.  The call flow in this posting allows an administrator the ability to block any number they want including anonymous, restricted, unavailable, etc.  

I will post more specifics in a day.

Dan Keller
Technical Marketing Engineer

Content for Community-Ad

Spotlight Awards 2021

This widget could not be displayed.