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 *

Cisco Employee

 Re: Adam Perkins observation about ILS/GDPR and this application note. 

Cisco itself was looking to implement this feature in their global SME environment.  But after observing the same issues that Adam observed, I did a deep dive on what was happening.   Here are the results of what I discovered.

As calls flow through the partitions and CSS to block numbers, when the calls exit the filter number partition (where patterns are blocked or allowed), the method by which the ILS learned patterns are stored cannot be found through the CSS of the ! xlate pattern in the filter partition.  I saw something similar when customers used this call flow with contact center.  To reach the agents on CTI redirect after the call flow, the original device had to have the agent DN's available.  This was easy because agent DN's are typically not DID's, so we could just add those to the ingress gateway and reach the agents.  But...the ILS learned patterns need to be available to the first device that routed the call to be routed successfully.  But the first device to route the call is the original SIP trunks and by adding the partition of the ILS learned patterns directly into the trunk's CSS, you will bypass the block logic because the GW can resolve the dialed number directly.  Since this appears to only affects SME customers using GDPR/ILS, I have not yet been able to resolve the issue, nor has UCM Development taken on any effort to address the matter.   So for the time being, we have documented the limitation as we investigate the best method to solve the issue.  



Dan Keller

Technical Marketing Engineer

Cisco Systems


Hello I have a scenario where calls are being delivered to CUCM with alphanumeric characters for the calling party number/From.   In this particular example these are call backs from customers in Skype for Business Environments.  For example if I do a call back from a Skype for Business meeting my caller id/from shows as wwatkins@  It will show something different for other users jsmith@ for example.   Is there a way to identify all alphanumeric strings in the from field and convert them to a calling number that will pass through CUCM inbound call blocking?

Cisco Employee


I am not entirely sure what you are asking for.  Since you are asking about user id based caller id strings, I will assume you are using SIP Trunks for interconnect.  Are you also using the LUA script?  The LUA script is used only on inbound calls and will not be invoked on outbound calls.  

With that said, if you can explain the call flow that you are using and what is displayed on the devices involved...and where the problem is seen, I will try to help you understand where the issues lies.  



Dan Keller

Cisco Systems


Yes SIP trunks are the interconnects.  Calls flow is as follows.   


Customer on premise SFB2015>>PSTN (ITSP)>>Cube>>CUCM,  I have not tried the LUA script as I don't think that will resolve the issue here as the  From filed is not Null, Anonymous, or Restricted.  It is basically the original username/sip uri  of the caller that is making the call back from the SFB meeting This being passed over the PSTN and on to our Cube and then to CUCM.   Invite to CUCM looks like this.


INVITE sip:19000@ SIP/2.0
Via: SIP/2.0/TCP;branch=z9hG4bK76997b92dff7eb7
From: <sip:wwatkins@>;tag=398454837~5aa1cd29-4fe9-494b-b45f-d98973c0d6da-40073169
To: <sip:19000@>


As you can see the From:  has wwatkins as the calling number  This will change based on which user in the Skype environment is making the call back.   CUCM is denying the call based on inbound call blocking as a result.  Call backs from the same SFB system to cell phones work they just show an unknown number.   Seen this with two or three of our SFB customers.  Obviously I can reach out to the customer end to try and have them send the right caller id, but don't want to have to reach out to each customer if there is another way to resolve this. 


Hi, Dan,

I have followed this document to apply this feature for a big customer using CUCM version 11.5 and SIP trunk through Oracle SBC. It is tested to be working fine until a few hours later, when the anonymous calls start to get blocked. It seems the script get disabled for some reason. I have modified the lua instruction threshold to 1500 but still the same thing. The script works for a while and then stops. Do you know where I can monitor the status of the script?




We also encountered the same thing recently as Quan...  (Except on CUCM 10.5(2) and CUBE SBCs)

From looking at SysLogs, we can see that this was due to the Lua Script Memory Leaking and effectively running out of Memory.  It didn't matter what we set the memory to on the SIP Normalization Script page, it still ran out of memory but just took longer to do so if increased.  This can be monitored through RTMT Performance Counters.


To work around this for the moment, we have stopped the Script from being disabled on the "Script Execution Error Recovery Action" and "System Resource Error Recovery Action" and set both of these to "Reset Script".  Our testing showed that there was no adverse affects when the script errored and reset, calls remained in progress and new calls still functioned correctly for both Anonymous and specified numeric Calling Party ID.


I am trying to work out which part of the script is Memory Leaking but my Lua Scripting knowledge is that of an amateur! :)


When looking at the SysLog, I can see that the Error is always "not enough memory".  I had hoped that it would show which function was causing the memory leak but I have seen all functions of the script appear in different error messages.


Things I have tried:

I have tried adding a Garbage Collection to the script but this had no affect apart from causing the script to not work at all.

I have tried removing all unnecessary blank lines and spaces including all comments/non-required text (have known this to cause problems on other scripts previously so thought I would try it)


Before configuring Blocking Calls Based on Calling Party ID, I had another simpler script running on the same Trunks with no issues.  I have moved what that script was doing to the CUBEs and is now a SIP Profile on the CUBEs for an outbound Dial-Peer so has not been "added" to this SIP Norm script.


If Dan or others could look at it and possibly see where the problem is, that would be great.

Cisco Employee


I have responded to you in a private message.  For everyone else, there was a memory leak in the original v5 of the LUA script.  I have identified the issue and corrected it in the v5a of the script.  That is the version of the script that is now available.  


Dan Keller

Technical Marketing Engineer

Cisco Systems



I have applied the most updated lua script Dan provided for a while, and it works perfectly without any further memory leak.


Thanks so much, Dan!




Thanks Dan...

For some reason, I had downloaded the v5 of the Lua Script and not v5a :)

I now have v5a and can see the parts added for OPTIONS Ping.  I'll get round to updating it later today.


Thanks again.



hi guys,


i have a sip trunk from avaya to cisco 11.5 (PRIs are on avaya side for now until we fully migrate from avaya). this call block based on calling ID is not working when we call with anonymous number.   (I am allowing anonymous #s)

error msg is


SIP/2.0 400 Bad Request - 'Malformed/Missing Contact field'
Via: SIP/2.0/UDP;branch=z9hG4bK-6c622aa-75f76aed-367e94ee
From: "RVH"<sip:anonymous@anonymous.invalid;user=phone>;tag=b08047b8-64511c0a-13c4-55013-6c622aa-c3e04d9-6c622aa


i already have the avaya normalization script "CS1k_ucm_interop_Lua" in place for the sip trunk.  if i have to add SIPTrunkAnonymousCalls_v5a.lua as well. how do i add it to the CS1k_ucm_interop_Lua script?????


thank you.



Hi Dan,

Great work on this and your dedication to keep assisting us all.

Quick question, Have tested the LAU script on CUCM v12.x?

Many thanks


Cisco Employee



The script has been tested on UCM 12.x versions.  Much of the recent work related to context was done under the 12.5 version.  So you can use this with assurances that it's been tested and will be supported. 



Dan Keller

Technical Marketing Engineer

Cisco Systems


Great document. I went through the configuration points and I wonder if this set of TPs can be used in opposite way - I mean to block all calling numbers and allow only those with specific ANI (calling number).


I've specific request to block all incoming calls to a specific DID number except few granted mobile phones.


I would appriciate any feedback :)


Hi awentland,

One way you can achieve what you are looking for is by further expanding on the the CSS and PTs that are part of this solution.


Using the existing CSS and PTs from the original post, do the following:

1)  Create new PT (e.g. "Filter_List_12345")

2)  Create new CSS (e.g. "To_Filter_List_12345") and add the PT created in step 1

3)  Create new Translation Pattern in PT "Inbound_Calls" for the Called Party Number you want to have different Blocking Rules for (e.g. 12345).  As with the existing catch all ("!") Translation Pattern, set the "Route Next Hop by Calling Party Number" but specify the CSS as the newly created CSS in Step 2.

4)  Create new Translation Pattern in new PT (created in Step 1) for catch all ("!") and use Route Option Block.

5)  Create new Translation Pattern in new PT (created in Step 1) for each Calling Party Number you wish to allow.  Use the Route Option Allow to allow calls from that Calling Party Number to get through to the destination DN.  (CSS set to "Internal_Phones")


This will block all calls to a specific DID/DDI/DN with the exception of those Calling Party Numbers you have created Translation Patterns for in Step 5.

In order to expand this to more individual DID/DDI/DN, you will need to create CSS and PT for each destination so you can have the different "rule sets".





Dan Very Nice Doc brother>>

i have an issue can u help me ?? 

the problem is the call blocking in the cucm was configured perfectly and some one  have changed the configuration of the call blocking old employee he(ruin it ) right now i deleted the blocking configuration and configure a new one like the doc u post but the problem is all calls are blocked all numbers,  it is a call center and there is alot of spam calls when i try to block a certain calling number all numbers are blocked,,, btw the GW is a trunk line so can u figure out the issue !!! 
can the sip profile affect call blocking !! because in the logs he changed something in the sip profile could be the prob here !!!  but it is not clear to me what is it ??!?!