Showing results for 
Search instead for 
Did you mean: 
Cisco Employee
Cisco Employee


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 *

IT Department

I will reach out to Dan privately to share something regarding a Cisco device that carriers use, the Cisco IAD 2400, has a role here after getting up to the carrier's engineering department.

Its all one vender, Cisco CUCM, Cisco voice router with MGCP, and Ciso IAD 2400 so hopefully all the internal Cisco teams can work together on this.



The reference of ‘NULL’ is referencing the word NULL versus (NULL or null) is referencing no characters

  • The keywords 'NULL' and 'ANY' are not supported in new translation rules, but these keywords can be replaced by regular expressions similar to SED.



This is a great article and i've tested this scenario to block calls with success.

However I am trying to expand on this concept to do the following:

(1) Filter a call based on the calling number based on the concept in this article

(2) Instead of blocking the call, route the filtered call to a voicemail account.

Once the call hits the translation pattern based on the calling number, I was thinking that the CSS of the translation pattern needs to contain a blank translation pattern, then the blank translation pattern will have a CSS containing the internal numbers.

Basically I need to understand how to disable the Route by next Hop function after the call has hit the translation pattern matching the calling number.


We just put the destination number into the Called Party Transform Mask field. Works like a charm.

Michael Tierney

I've looked through the comments thread (which is impressively long) and I don't think this is a duplicate question: is it possible to route based on a combination of the calling party number and the dialed DN? I have a number I need to block from calling a particular number on campus (let's say the athletics main number for example) but I need to allow the caller to reach our campus security, our medical centre, and other numbers. Is it possible to block a combination of calling party and called party, but allow the rest of the calls from the same calling party through?


I tried \!, but it did not work...however X! did work.

Scott Bailey

I tried implementing the approach as per the document and it did not work.  It looks like I may need to try the pattern=\+! as mentioned here.  I haven't gone into the traces but the behavior of all calls being blocked is what I experienced.

Vivek Batra

What you configur as TP depends on your requirement. If you know exact DNIS being received, you can configure more specific pattern, else \+!

- Vivek



we installed the blocking/allowing translation patterns as described by Dan on a cucm 8.5.1 Cluster without problems.

for allowing/blocking anonymous calls we did not import lua script, we changed the config of our cisco ios pstn/sip router - blocking/allowing anonymous calls works fine with the <Null> translation pattern.

Our Changes we have done on the Router -

voice service voip



   privacy pstn

   privacy-policy passthru

In the debug ccsip messages on the router

we see

Invite (without privacy pstn)

From: "anonymous" <sip:anonymous@>;tag=F2E4B38-F43

Invite   (with privacy pstn)

From: <sip:anonymous@anonymous.invalid>;tag=F374F78-B73

Maybe that helps  :-)



Cisco Employee
Cisco Employee

had a customer use this template and found that to route or block the call in step 8 of the configuration you will need to include some valid CSS.  None will not allow blocking the call nor routing it to a common number (such as the security desk).

Thanks - great document by the way.



My client is a little hesitant about the lua script since it's not TAC-supported. Are there plans to have TAC support this specific script? If not, what are the alternatives to getting support if we run into issues with it?

Cisco Employee
Cisco Employee


There are no plans to make this a TAC-supported script, but I do support the script.  I have worked with many customers on the script to make sure it works in their environment.  TAC will accept the customer request for a case related to this call flow, then TAC will work with me or I will work directly with the customer to correct any problems, then TAC will close the case.  Almost every TAC engineer is aware of this call flow and script and if they need help, I will support them and the customer.  I have helped 10 to 12 customers over the years with custom scripts to make this flow work in their environment.  


Dan Keller

Technical Marketing Engineer

Wayne Tweedle
Community Member

Just an FYI ... I ran into this same issue "Translation Pattern cannot begin with.!@-+?" on CUCM  After reseaching an hour I decided to try IE (as opposed to Chrome. No more pop-up error message.  It now allows me to create a translation pattern with a leading "!".  The real irritation/time killer was that the pop-up error message looked so official and 'all knowing' as if generated by CUCM.  (And yes I know IE is the Cisco recommended browser).  Oh well, live an' learn.

IS Department

I administer a BE6000S with UCM v10.5.2.10000-5 and have actually previously tried a configuration similar to the one described in this thread solely to block "anonymous" calls toward one specific extension because the "Reject Anonymous Calls" function was "not working."  When I opened an SR, the TAC provided a similar configuration that I tried, and external callers could reach the destination unless they did not have a caller ID number (desired outcome), but internal callers could no longer reach the extension in question at all (new problem).  Given that, I have a few questions regarding this document:

1)The UCM in question was provisioned using CPCP, and it utilizes the parent 2921 as a SIP trunk gateway.  There was no script installation involved in the configuration I had performed.  Is it possible that the TAC person found this thread and provided the instructions without directing me to install the script, leading to that issue?

2) In the SR mentioned earlier, it was determined that the "Reject Anonymous Calls" function was functioning as designed and the initial issue was caused by the fact that the incoming calls had "Unavailable" as the P-Asserted-Identity, and the UCM feature only blocks "Anonymous" and "anonymous".  Unfortunately, using a sip profile to do this:
request INVITE sip-header P-Asserted-Identity modify "Unavailable" "anonymous"
leads to calls that have a caller-ID number but "Unavailable" as a caller-ID name to also be blocked by the "Reject Anonymous Calls" functionality.  I have had a newer SR opened regarding that for some time, but the engineer has been unable to find a workaround to only change the P-Asserted-Identity when the caller-ID number does not include digits.  Is there any chance I can do something like this to reach that goal, or am I going to need to re-involve the solution discussed in this document?

3) Since we have the parent 2921 acting as a gateway, we actually normally block calling numbers using the same methodology that was used in our previous CME (a translation rule with the reject tag paired with the call-block functionality at the dial-peer).  I actually found this document while searching for a way to allow end users to block calling numbers for their extension only.  Based on this document, I am guessing there is no way that end users can do that, but based on some comments, I think I could do that by setting up a separate filter partition for inbound calls for each extension that I want to filter against and using the extensions as translation patterns, however, and this may be where I got messed up in (1), I believe it would be necessary to change the extensions so that they don't match the DID (IIRC, I had to do this in the original SR's steps since we only wanted to block the calls to one extension).  Is that true, or can I use the same pattern in the incoming call partition and the final internal partition without causing problems so long as the SIP trunk's CSS is set to a space that only includes the incoming call partition and the internal phones can't see that partition in their CSS?

Cisco Employee
Cisco Employee

Part of the reason for writing this application note was the fact that the "Reject anonymous calls" did not fully address customer requirements for blocking calls as well as the fact that a company could not block other types of numbers coming into their enterprise.  I would recommend contacting me directly at to continue the conversation specific to your deployment.

I will try to answer each question posed as best as possible.

1) From what I understand of CPCP, this will not affect the deployment of the SIP script (if needed) nor the call flow for the inbound calls.  The script is intended to work with the documented call flow, but it could be used outside the call blocking call flow.  If you have the SR for the case that I can review, I can provide you a better response to the question.

2) The lua scripting that can be applied to a SIP trunk can do this.  The call blocking lua script looks for the text "Unavailable", "Anonymous" and "Restricted" in the PAID, PPID, RPID and From fields.  The script can be modified to look at only the PAID field and leave the rest alone.  But if you start changing only one field, you need to understand UCM's logic on which field will be used for calling party display as well as the field that the 'reject anonymous call' uses for rejecting calls.  

3) There are a couple of options regarding this question. Since the first ! translation pattern on the inbound GW represents all dialed numbers.  If you want specific numbers to get calls irrespective of filtering, then define an xlate for that number and bypass the filter partition and send the call directly to the endpoint.  IF you want to block calls to specific numbers, then you can specify those numbers that need blocking in an xlate pattern that go through the filter logic and all other numbers will route directly to the phones.  I don't know exactly how your dialplan is set up, but I do not believe you need to add new partitions/css or change existing number.  
I will admit that this call flow will not allow users to define the numbers that they want to block.  All numbers to be blocked need to be entered by the admin.  

If you need additional information about options related to item 3, please contact me directly at the email provided above.  


Dan Keller

Technical Marketing Engineer



Can we apply the LUA script to an individual phone instead of the SIP Trunk and make it work ?

Thank You

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers