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.
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 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 *


Hi Dan,

I found your document and call flow configuration very straight forward and it works well for us. Inbound calls to DNs that are in PT-Internal route normally as expected.  Some of our DNs however are assigned to the <None> partition. Inbound calls to a DN that is the <None> Partition seem to be blocked or simply do not get completed.

These DNs in the <None> Partition are IPCC extensions.

The CUCM System Guide states that

"Before you configure any partitions or calling search spaces, all directory numbers (DN) reside in a special partition named <None>, and all devices are assigned a calling search space also named <None>. When you create custom partitions and calling search spaces, any calling search space that you create also contains the <None> partition, while the <None> calling search space contains only the <None> partition."

Do you have any thought as to why a call from the outside throught the gateway to a DN in the <None> partition would be unsuccessful with the configured call flow in Figure 1 above?

Cisco Employee

Jeffery, thanks for the feedback on the document.  After reviewing the information you provided, the only reason I could figure that the calls would be unsuccessful in extending the call to the IPCC extensions in the <none> partition could be caused by the fact that the redirect from CTI (I'm assuming IPCC agent has call delivery from an IVR) uses the CSS of the source device (the ingress GW) and instead of matching the IPCC extension directly, the GW is going through the call blocking logic a second time and failing.  There has been special consideration for IPCC agent extensions that the partitions that hold the IPCC agent extensions be defined in the ingress GW CSS.  Althought I would expect the call to match the IPCC extension in the <none> partition, it sounds like the ! takes precedence and prevents the call from completing.


Dan Keller

Technical Marketing Engineer


I applied this procedure to CUCM 8.6.2 with a SIP gateway and it worked just perfect..for blocking the numbers like it shoud. The problem is, now when I dial out from the Call Manager to any outside number or inside extension, the interdigit timeout is invoked. The call out just sits untill timeout then rings out fine. It didn't do this before I applied this procedure. Any thoughts?

Cisco Employee

This problem will occur when the phones can find the ! translation pattern in their CSS.  Please make sure that the partition that has the ! for inbound calls is not available to phones for outbound calls.  That is why the document recommends creating a new partition specifically for the !.  That way the phone's CSS do not have to change but the inbound gateways (MGCP, SIP, H323) just have to point to the new partition and everything will work just like before, only you can block inbound calls.


Dan Keller

Technical Marketing Engineer


Strange thing Dan, after I had shut the servers down for the night in my lab after this interdigit timeout thing started hapening after I followed this procedure to the tee, I started the Call Manager servers up again yesterday and everything worked perfect. No interdigit timeout, and call blocking worked like it should. I have no explanation for this as I did not touch any other configs.

Cisco Employee

Thanks for the feedback that it's working as expected.  I too am a bit puzzled why it would not have worked before the reboot.  Typically changes you make to the dial plan trigger database changes that replicate through the cluster.  So if there was a database issue, like a replication failure to a node, then a restart of the cluster or that node would not fix that issue and the problem would persist through a reboot.

With that said, I would recommend that you check the replication status of the cluster just to be sure everything is replicating and working as expected. 


Dan Keller

Technical Marketing Engineer


Sorry to beat this question to death, because I see it being asked but I don't see a solution.

Was anyone able to get this to work and still allow anonymous or unknown callers through on a pre-8.6 CUCM?  Mine is at and the blank translation pattern I created according to the article does not allow them through.

It blocks specified numbers perfectly, but we're a legal industry and many government entities block calling display, so we're not able to use it without permitting them.

Thanks for any info and the excellent article.

Cisco Employee

I might have some time this week to go back and verify the pre-8.6 operation.  Can you help me understand the situation you're encountering.  Specifically, what is the inbound gateway (SIP Trunk, MGCP or H323)?  And if you have any traces from the failure, it will help me recreate and respond to your query.  For traces, I would need the approx time stamp of a rejected call and I should be able to get the information I need. 

At this time, I will take the conversation off line...but I will update this thread once I have a positive response for you.

Please email me direct at


Dan Keller

Technical Marketing Engineer

Community Member

I am having an issue getting this to work, maybe you can help. I have an FXO porton a 2811 router connected to PSTN. Caller ID is enabled and the attendant DN is *97. I changed the CSS for this FXO port to the equivalent of you 'Gateways' CSS, and the translation pattern in a partition in this CSS is "*!" (as I had to account for the prefix of the * in the internal extensions). This pattern also has route next hop by calling party ID and a CSS equivalent of your 'To_Filter_List'.

The issue seems to be at this point, no matter what translation pattern I put in the Filter_List partition, when I call the number that is connected to this port, it picks up and I get idle silence for 15 seconds (I assume inter-digit timeout) and then an error message. If i put in a null translation pattern, I can route the call fine. When the call gets to the IP phone, the proper caller id information is displayed. Any ideas?

EDIT: this is on version 9.1.2


We found that those directives only change the name.... not the incoming number.  We got it to work by modifying the actual number that we found in the debug.  This is what actually got it to work for us.  We change the "anonymous" or "Restricted" to a series of 10 zeroes so we could also block anonymous incoming if we choose to by blocking the "0000000000" in the translations mentioned above.  Verizon and Sprint and TMobile all use one of those words in the SIP header.  Here's what we found actually works:

request ANY sip-header From modify "sip:anonymous(.*)" "sip:0000000000\1"
 request ANY sip-header From modify "sip:Anonymous(.*)" "sip:0000000000\1"
 request ANY sip-header From modify "sip:Restricted(.*)" "sip:0000000000\1"


If you do a debug, you'll see the header looks a bit different from what you were probably expecting.  Hope this helps!



Great Document & Explaination !!!



Cisco Employee

In case numbers are being modified in E164 format, change the translation pattern from '!' to '\+!' so that it can match a number starting with '+'.

Here translation patters are configured as '!' which accepts any number of digits between 0 through 9, but not '+'. (  - Page 168).

If this is missed, all calls would be blocked.


Do you know of any changes to this process in the later 10.5 release?  


We are migrating from a appliance based 8.6 system over to a brand new virtual 10.5 system.  The 10.5 system is a ground up built cluster that we are migrating over to.  We had call blocking working just fine on our 8.6 system, with the instructions listed above.  But when we tried to implement this same process on the new 10.5 cluster it doesn't work.


It will block any call coming down that particular MCGP gateway PRI.  We have about 16 PRI's to apply this call blocking CSS on, but I can't get it working right yet.  I'm just working on 1 PRI as to not kill all incoming calls into my system.


Thank you,



Cisco Employee


First off, nothing has changed between UCM 8.5 and 10.5 that would invalidate the process or script.....but I had a report of the script not upgrading correctly.  But I have not been able to confirm the situation.

I would like you to help me out.  Can you look at your script on the 10.5 system.  Check the 'replacementNumber' setting.  It should = "sip:\" and not "sip:\\".  It's possible that the upgrade process added a second slash that will cause the script to no longer work.  The fix is easy enough....remove the second slash. 

Please update me if this is the situation.


Dan Keller

Technical Marketing Engineer  


Are there any plans for CUCM to be able to handle anonymous calls natively without using the LUA script?



Content for Community-Ad