Blocking Calls Based on Calling Party ID


Mon, 11/02/2015 - 10:07
Sep 7th, 2011

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.

Kasiraman S Mon, 01/23/2012 - 06:24


Nice doc. Thanks for the explanation. I would like to understand the below point and I do not think it is necessary for the called number to have a partion . Please explain me if I'm wrong.

"(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.)"


dakeller Mon, 01/23/2012 - 10:02


This comment was added after the intial publishing of this document, but I can still explain. Becaues the <none> partition is available to all calling devices, if the called party numbers are reachable in the <none> partition this will lead to unepxected call routing.   So when a call comes in over a PRI for a number that is defined on a phone, DA will return the number on the phone as the destination since it is a better match than the ! pattern.  So the phone will ring.  In order to use the blocking feature in this document, all phone DN's must be in a partition that is accessible after going through the blocked number partition to prevent direct call routing.  

If you need more informaiton or this does not answer your specific question, please ask your question again and I will respond. 


Dan Keller

Technical Marketing Engineer

IT Department Tue, 10/27/2015 - 11:35

After a few weeks of troubleshooting after applying this with TAC and our Carrier it turns out that some companies use old PBX systems that deliver their caller id as <NULL>.  This is fine if a customer is using H.323 or SIP because you can convert that on the gateway to something call manager understands.  In our case, since we run MGCP we do not have any ability to modify the incoming string to Call Manager that comes to us on PRIs.  


None of the translation patterns in this example will allow a NULL calling party to make it through the filters.  This blocked many of our customers across the United States from reaching our call center.


TAC has seen this several times now ex SR 636825945.  Do not attempt this configuration with if you run MGCP, either switch protocols, or wait for an enhancement in a version of Call Manager newer than 10.5 that we run.

bvanbenschoten Tue, 10/27/2015 - 12:51


Is the telco sending you a blank (non existent) calling number or actually sending the string "<NULL>" as the calling number?


I've tested this successfully when the calling number is simply not provided. I haven't run into a case where the telco is sending some text string.

IT Department Mon, 11/02/2015 - 10:07

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.

dakeller Thu, 10/29/2015 - 09:47

Just to be clear here, UCM will work when the calling party is not present or set to a NULL.  This call flow will not work if the SP sets the calling party value to the ASCII text string "NULL".  I have reviewed the SR TAC case and the provider is setting the calling party number to:

Ie - Q931CallingPartyIe -- IEData= 6C 06 00 80 4E 55 4C 4C

4E 55 4C 4C is the text string "NULL".  

When the calling party is an actual string value, UCM digit analysis will always return a 'noPotentialMatchesExist' and block the call.  This was the same issue with SIP trunks and why I had to create the LUA change the anonymous/restrcited text to a true NULL value or a digit string that digit analysis could process.  

At this point, I will say that I have never seen a customer report this problem.  I would recommend that you ask your provider to not send a text string in the calling party IE.  If they want to send NULL in the display IE, that is fine, but just not the Calling Party field. 

Unfortunately, this situation cannot be corrected through UCM configuration.  UCM does not allow me to change the MGCP calling party info like I can with SIP trunks.  So this would need to be corrected on the Service Provider side of the connection.


Dan Keller

Technical Marketing Engineer

IT Department Thu, 10/29/2015 - 10:21

I was the one who submitted the SR.  

I emailed COX Communications engineering department to see if they are the only US carrier who makes NULL appear as ASCII but in the past they said they pass whatever is sent to them and either another US carrier sending CallingParty info to them is doing this or the old PBX system on the remote end.

Over the last 3 months these complaints came from customers all throughout the midwestern United States, we did not get any reports from East or West coasts which leads  me to believe maybe there is a midwestern SP/Carrier servicing Michigan down to Ohio that delievers NULL as ASCII.

I would put in a feature request for MGCP.

dakeller Thu, 10/29/2015 - 10:25


I understand what you're saying, but there is no defect to be fixed here.  This app note uses standard call processing that has been the core of UCM since 2001.  The addition of the 'route next hop by calling party number' was introduced in the UCM 8.0, but this also uses standard call routing.   Our digit analysis engine has never routed on text string (well, at least not until URI support was added).  

Additionally, I have personally worked with 100's of customers on implementing this call flow.  This is the first time I have ever seen a carrier send in a text value in the CallingPartyie field.   

With that said, let me see what I can do on UCM to address this problem.  Just so you know, I will not be able to use the standard call routing tricks I can use with numbers because I have to match on a string, which cannot be inserted into DA using standard methods.  I will need some time to set up an emulation of this situation, so it may take a week or two to respond.  

But I will respond with an answer on if this can be fixed in UCM or not.

Dan Keller
Technical Marketing Engineer

evangaever Mon, 03/12/2012 - 07:51


If I'm not mistaking, a translation pattern is always checking the "Called number" and not the "Calling number". In that sence the procedure would not work when you are trying to block incomming caller IDs. Or am I missing something?

Thanks for explaining this,


dakeller Mon, 03/12/2012 - 09:34


In CUCM, there was a new parameter added to a translation pattern that would allow you to 'route next hop by calling party number' box.  This parameter was added to identify secure endpoint calling, but after testing, the implementation of this feature allowed it to be used to block calls based on calling party number.  From the call processing standpoint, CUCM send the calling party number to digit analysis for a match instead of the called party.  The returned match will be a translation pattern that is set to 'block' the call.  What's nice about this new parameter is that instead of forcing the block to occur on an H323 gateway, the blocking logic can be done on the CUCM itself.  So the docs title is accurate for the function it provides.


Dan Keller

Technical Marketing Engineer

troyputnam Fri, 03/23/2012 - 12:38


I tried this setup on a POTS line to a FXO card on the router.  I followed the setup steps and assigned the "gateways" CSS to my FXO port config.  I reset the FXO port and tested.  The translation pattern I configured to be blocked was my cell phone number.  When I call the number assigned to the FXO port from my cell the call go's thru and show a caller ID number of 0. 

Any idea where I am in error or does this not work on an FXO (mgcp) port. 

dakeller Fri, 03/23/2012 - 13:49


First off, does the FXO port accept CLID?  Were you were getting caller ID in the past?  If yes to both, what I will need from you is to turn on the tracing on the CUCM, recieve a call on the port, then send me the SDI trace output from the CUCM.  Include time of day, calling/called party and the block pattern you have defined and I will see if I can determine why it's not working the way you expect it to be working.


Dan Keller

Technical Marketing Engineer

troyputnam Mon, 03/26/2012 - 06:27

Yes, with CUCM 8 and above, there is now a "enable Caller ID" check box for the FXO port.  I have that checked and reset the port.  I also have it enabled on the CLID for that port.  I will work on providing you the SDI trace information sometime today.  Thank you for your help!

CHRISTOPHER YUEN Wed, 03/28/2012 - 10:33

Ran into an issue with this while trying to implement e164 calling party transformations.  Calling party ID based blocking would not work if I prefixed +1 or + to inbound calls.  And it didn't matter whether I prefixed it using calling party transformation patterns or using IOS voice translation rules.

Found that you need to have \+! translations patterns in the 'Inbound_Calls' and 'Filter_List' partitions.  And blocked calls would need to start with \+.  If you don't include that, then those calls will not get blocked.

juniper76_2 Wed, 05/16/2012 - 06:47


I need to implement this for my contact centre which has calls delivered via an MGCP gateway. To complicate matters i also have 2 H323 gateways within the cluster! By configuring this in Call Manager for the MGCP gateway am i likely to cause any issues on the H323 side of the fence?!

I don't need to block calls based on the the ANI for devices that receive calls via the H323 gateways, just the contact centre!

dakeller Wed, 05/16/2012 - 07:20

I'm not sure I understand the concern.  You would create the partition for the numbers you want to block, then change the CSS on the gateways you want to block calls on.  So in your case, just change the CSS of the MGCP GW to route through the caller id blocking partition, but leave the H323 GW's with the CSS to reach phones directly. 


Dan Keller

Technical Marketing Engineer

Bryant Onojeta Wed, 08/15/2012 - 10:26

This solution works great, my customer is very pleased with the ability to block incoming calls now.


Systems Support Engineer

CHRISTOPHER YUEN Fri, 11/16/2012 - 07:05

I ran into an issue the other day where inbound 'anonymous' calls are being rejected.  I don't have any translation patterns to block, and I have the blank translation pattern that, if I understand it correctly, should've matched this and allowed it through.

Has anyone seen this or can anyone confirm if they've successfully received inbound 'anonymous' calls?

Thanks in advance!

dakeller Fri, 11/16/2012 - 07:18


I ran into this very early on and I do have a solution.  I will send you a LUA script that will allow you to identify and deny anonymous callers.  I expect to include the LUA script as part of this app note after a bit more field exposure. 


Dan Keller

Technical Marketing Engineer

CHRISTOPHER YUEN Fri, 11/16/2012 - 07:21


Thanks...I appreciate that.

One thing though...the issue I'm seeing is that 'anonymous' calls are being blocked but I don't want them to be.  I don't have any block patterns at all, yet these calls are being blocked.

dakeller Fri, 11/16/2012 - 07:48


I read it the other way around.  What patterns do you have defined that you are blocking?  In the configuraiton above where you have the <NULL> and ! patterns as allowed, the anonymous tag will actually match the ! and continue throught for call routing.  Unless you have something different set up, anonymous will work out of the box.  Please email me directly so I can get some specifics on what you are seeing.


Dan Keller

Technical Marketing Engineer

dakeller Fri, 11/16/2012 - 07:36


Actually, I've had enough feedback that the lua script works and does not cause any adverse affects to call processing.   I have added the lua script to this posting. Just download and deploy.  Please let me know how how effective this solution is for you.


Dan Keller

Technical Marketing Engineer

JMistrot1 Thu, 12/06/2012 - 18:59

Wondering if anyone has implemented this but run into an issue where calls that are ultmately bound for a CTI routepoint to UCCX get rejected.  I just opened a TAC case around this.  I used this page to build my implmentation plan and everything seemed fine until later in the morning we discovered that DNs inbound from the GWs bound for a CTI RP and UCCX trigger get rejected everytime.

dakeller Thu, 12/06/2012 - 20:30


Unless you change the calling party number to something that UCCX does not accept, the call egressing from the 'route next hop by calling party number'  will look like any other call.  Since I am the author of this doc, I am very interested in seeing what is happening.  I could not find the TAC Case, so can you forward me the SR number and hopefully there will be a trace file for me to look at.  Let's take the troubleshooting off line and I will update this thread when I figure out the issue.


Dan Keller

Technical Marketing Engineer

CHRISTOPHER YUEN Fri, 12/07/2012 - 03:58


Are your CTI RP's and ports in a different partition from your phone DN's?  You may want to double-check the CSS that you have applied to the translation patterns that allow the calls in to make sure they can hit both the CTI RP and the CTI ports themselves.

fergus.w Mon, 12/17/2012 - 16:57

Hi Dan,

I think the CTI issue is summed up well in the "Cisco Unified Attendant Console Troubleshooting Guide v8.6.x". (

On page 2-8 it mentions:

"As CUxAC uses TSP and CTI to move calls, the function of CTI Redirect performed on the call forces it to inherit the CSS of the gateway which does not always allow calls to all phones. Modify the gateway CSS to accommodate this and resolve the problem"

My understanding is this means the gateway CSS needs access to the Route Points, CTI Ports and Agent Phones.  That is to say, CTI/TSP connectivity doesn't honour any CSS changes through translation patterns as the redirect uses the original device's CSS.  Certainly this has been my experience since CCM 3.2.

Unfortunately this would then mean any calls to a CTI/TSP connected system could not use the flow to block on CLI as the gateway CSS prohibits access to any other partition than the initial "!" tranlsation pattern, and hence prevents the redirect to the CTI/TSP devices.

It would be ideal if CTI could be reworked to honour changes in CSS through translations, but until that time, I suspect we're limited in how we can apply some of the more interesting dial plan features.

Hopefully I'm mistaken and things work differently to how I think.



dakeller Thu, 12/20/2012 - 06:50


You understanding is correct. By default, on a redirect, the CSS of the calling device (GW or Phone) is used to redirect the call.  The CTI application can set the redirect CSS to use, but only the CTI application can do this. You cannot set this behavior at the CUCM level. 


Dan Keller

Technical Marketing Engineer

Robert Burlingame Tue, 04/09/2013 - 07:33


I'm with Christopher on this one. We implemented this and "anonymous" and "unavailable" callers get blocked. This is due to the fact that translation patterns only recognize certain numbers and characters. They only recognize the following alphabetic characters: A,B,C,D (capital only)

I realize the above article is dated, but, I can't find anything to the contrary.



markjpurdy3316 Fri, 04/12/2013 - 11:18

Dan, I've also run into this configuration issue.   It appears because I am filtering on SIP trunks, the <null> translation does not allow "restricted", "anonymous," and unknown strings to pass.   Since SIP does not recognize the various dial plan types as does MGCP,  what options do I have other than some CUBE configuration.   I want to pass these anonymous calls thru.    How would your script work for this instance?  

dakeller Thu, 04/18/2013 - 07:55

The original configuration that automatically passed 'restricted' and 'anonymous' calls does not appear to work on all versions.  I am currently working on a way to simplify and ensure no version dependencies.  

So I would appreciate some feedback from the community on how you use this feature and how you would like the issue solved.

1) When blocking incoming calls with no number, specifically calls listed as 'restricted', 'unavailable', 'anonymous' or no numbers at all, will all 5 be treated the same?  Are you planning to block all 3 calls or would you plan to allow 'restricted', but deny the other 3?  Do you want the ability to treat the different types of anonymous callers uniquely?

2) If you plan on passing anonymous callers to your users, what do you expect to see on the display of the called phone?  Do you require differentiation of 'restricted' vs 'anonymous' vs 'unavailable'?  Would it be acceptable to classify all 3 to display the same?  Also, would it be acceptable to make all 3 appear as 'restricted'?

Please provide the feedback to me directly in a private message so I can work on the solution. 


Dan Keller

Technical Marketing Engineer

tm54189873 Thu, 05/30/2013 - 06:19


In response to "the original configuration..does not appear to work on all versions", could you please specify which versions have been tested that Route Next Hop By Calling Party Number has been validated on?

We have an urgent need to implement the block incoming calls based on ANI, using this new TP feature, but also need to pass both 'restricted' and 'anonymous' calls like Christopher, Mark and Stuart have described.  We are running version and hesitate moving forward with this implementation without validation since it will cause an impact by blocking these sourced calls.

In the interim I'll email you directly as requested indicating our preferences on your #1 and 2 inquiries in efforts to engineer a solution for all versions.



dakeller Thu, 05/30/2013 - 07:36

It's been quite some time since I did this script.  I thought I had written it against 8.5, but obviously I had not because it does not work in my retest.  So I might have tested 8.6, but  I cannot commit to that right now. This script does work on 9.x because Cisco added URI dialing capability to the digit analysis which means it could now handle alpha characters along with the 0-9*#ABCD. 

There was an addition to the original script that stripped the anonymous/unavailable/restricted that would allow the call to pass for all versions. 

I am working on newer version of the script so simplify the logic, but given my current workload, I do not see it getting coded, documented, tested and posted until July.


Dan Keller

Technical Marketing Engineer

gsimon@cisco Wed, 07/24/2013 - 11:59

Hi Dan,

Is the issue with restricted callerID calls not being allowed, specifically for SIP calls or it's happening for PRI as well?

Also is the null pattern required for ISDN or it's just for SIP?



dakeller Wed, 07/24/2013 - 13:20


Yes, the <NULL> pattern is needed if you want to pass a call that does not have a calling party.  This is very true for ISDN, but SIP trunks might be different because they will send 'Restricted' or 'anonymous', which will not match a number, so that is why I have included a script to handle these types of calling number.


Dan Keller

Technical Marketing Engineer

goku-sun Sun, 09/15/2013 - 11:15

Hi dakeller,

May I know the details of workaround for sending a call without calling ID via null translation. I met the same problem and is urgently seeking solution on this.

Many Thanks,


dakeller Mon, 09/16/2013 - 07:18


There is a lot of information missing to be able to answer your question.  What is the protocol into CUCM?  Do you have a Gateway or Trunk?  Are you looking to block NULL caller id's or do you want them to pass?  If you provide the details, I can provide guidance on how to correct the call flow to make this work.


Dan Keller

Technical Marketing Engineer

goku-sun Tue, 09/17/2013 - 11:48

Hi dakeller,

Thanks for your quick response. Please see the background below:

1) An etraIi PBX is interfaced to a new MGCP GW via QSIG links. With other MGCP GWs connected to 2 different Telcos "A" & "B", all under CUCM 8.6. For voice mails, the Etrali phones will access an ext (say "5000") and it directs the call to the CUC 9.X as no answer call fwd or all call fwd, with corresponding ext defined in the CUC.

2) The translations are used identify the calling ID from PBX and route calls to appropriate CSS's towards T1s of telco "A" and telco, say, 2XXX = DDIs of telco "A"; 6XXX = DDIs of telco "B"

3) All are worknig fine now after CPN is set up for all extensions from the PBX. Except that if a call orginates from PSTN, the call will drop after ringing some time if no answer or via call forward to the voice mail extension. If the call originates from another Etrali ext, voice mail can be left. If the translations are not used(then outgoing call from 6XXX will display as prime # of telco "A"), voice mail can be left from PSTN and extensions.  Is there anything altered after transation is done?

Etrali phones (2XXX, 6XXX) <-> Etrali PBX <->  QSIG links <-> Cisco MGCP VG  <->  CUCM <-> Cisco phones / PSTN (other MGCP GWs to different telcos, 8888-2XXX for telco "A", 9999-6XXX for telco "B")

Config (CUCM 8.6.1)

0) A MGCP VG is installed with QSIG links to interface PBX and CUCM, the partition of QSIG link is "PT_Etrali_incoming".  Another partition as "PT_Etrali_Translation". CSS's with "CSS_Etrali_incoming" and "CSS_Etrali_Translation" are created to include the partitions just mentioned respectively

A) A translation pattern defined as "!" with partition = "PT_Etrali_inoming" for the QSIG link of MGCP VG, CSS is "CSS_Etrali_translation". Option "Route Net Hop by Calling Party Number" is also CHECKED

B) 2nd translation = "2XXX", partition = "PT_Etrai_incoming" and CSS = "CSS_Etrali_Telco_A". This to route  2XXX call to Cisco ext or PSTN via telco "A" (to display his CLI to PSTN instead of incorrect prime# or unknown# )

C) 3rd translation = "6XXX", partition = "PT_Etrai_incoming" and CSS = "CSS_Etrali_Telco_B". This to route  6XXX call to Cisco ext or PSTN via telco "B"  (to display his CLI to PSTN instead of incorrect prime# or unknown# )

Many thanks,


dakeller Wed, 09/18/2013 - 12:28


I have read the configuration that you have set up and understand that the issue is calls from the PSTN will drop if the call is CFNA to voice mail.  But one item that is missing is the call flow.  Something like 'call arrives from telcoA, routed to Entrali PBX, CFNA back to CUCM to reach CUC'.  If the flow is like this, then there are 2 potential issues.  The first is that the calling party number is a PSTN number and the Xlate patterns you have for the Entrali trunk don't match to route the call to CUC.  The other choice is that the xlate pattern is matching the external number, but the CSS of the matched xlate does not contain the partition for reaching CUC at 5000.


Dan Keller

Technical Marketing Engineer

shohamshalom Mon, 07/13/2015 - 06:58

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




dakeller Sun, 07/12/2015 - 19:32


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

Stuart McGrath Thu, 04/25/2013 - 00:22

We tried this and had the same issue as Mark above. "restricted" and "anonymous" unkown calls do not pass when this is in place.

Has anyone figured out a workaround?

Robert Burlingame Thu, 04/25/2013 - 05:30

TAC has worked with me to try the following on our CUBE (gateway device):

voice class sip-profiles 1

request INVITE sip-header From modify “Anonymous” “999”



dial-peer voice 1 voip

voice-class sip profiles 1

Note: We've not implemented this in production yet, so, all warnings apply. However, we have modified the headers before and it seems to work as expected.


dakeller Thu, 08/08/2013 - 10:56

The call will be recorded in CDR's even if it's rejected through this method.  You can find calls that are rejected based on the rejection type you have set at the xlate pattern.   But I must warn you that there is no special indication that a call was rejected by this configuration.  So if you set the rejected reason code to something like 'Number changed (one not commonly used in CUCM), then you can look at the CDRs to find that cause code to determine which calls were rejected through this configuration. 


Dan Keller

Technical Marketing Engineer

ALI HYDER Fri, 08/16/2013 - 09:40


We have a user who is complaining that she is getting harassing calls from a particular caller. My questions is, is it possible to setup translation rule only for this user's extension instead of rule based on Calling party for the entire site?  We are running CUCM 9.1.1, I would like to know if I can match a call based on both a "Calling" and a "Called" party and then allow or reject it?



dakeller Fri, 08/16/2013 - 11:39


If you look at the method by which the calls are passed to the xlates that will block the call, I use the ! value.  That means a call to any number matches.  If you want to block for a single person, the ingress GW can have an xlate that matches that person's number that will send the call to the block partion, then you can block it.  So even though you cannot block based on both calling and called party in the same operation, you can accomplish what you want to do relatively easily.


Dan Keller

Technical Marketing Engineer

wdgarfield1 Sun, 09/08/2013 - 10:30

We are dealing with the Null callerID issue on the gateway router, using a voice translation-rule /^$/ to insert /0000000000/   In this way every call coming into the CUCM has some value appearing in the calling party field, even if it's a string of 10 zeroes. This allows these calls to pass through the callerID blocking without being blocked.

Bara Alhourani Mon, 10/07/2013 - 04:05

Hi Dan,

Thanks for the great document.

My customer runs CUCM version I have completed the steps on his system, after that I was able to block a certain caller but at the same time other callers were blocked.

I have recreated the issue in our lab CUCM version and found that the callers are not hitting the ! TP which is assigned to 'Filter_List' partition unless the prefix for the calling party in the incoming calls is configured.

Please find the attached picture:

if the system was configured as shown in the picture all other IP-Phones which are registered to CUCM 2 will not be able to dia 7070 IP-Phone, but if I configure prefix 6 at the calling party for incoming calls and modified the 8080 TP to be 68080 everything works properly (IP-Pone 8080 is blocked and all other IP-Phones are able to call 7070).

Please let me know why other IP-Phones were not hitting the ! TP ? and how should I proceed? CallBlock.png

ealeatherman@ma... Fri, 12/06/2013 - 06:30


I was wondering if the version dependencies/inconsistencies are still present in this feature with regards to restricted or anonymous caller id - particularly with CUCM 8.6(2). I'm doing some planning around implementing this blocking capability but I need to be able to permit these types of calls through. It seems based on comments above that there are still potentially some caveats for this.

Thank you for the excellent document and explanations by the way.




This Document

Related Content