cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Blocking Calls Based on Calling Party ID

227188
Views
170
Helpful
158
Comments

 

Application Note:

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

 

Introduction:

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.

 

Audience:

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.

 

image1.png

 

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.

 

Configuration:

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.

image2.png

 

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

image3.png

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.

 

image4.png

 

      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.

 

image5.png

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 14085551212@cisco.com 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 14085551212@cisco.com resolves to 14084441212@us-sj-ucm.cisco.com on the SME, then the inbound SIP trunk must have access to the partition for route string for *@us-sj-ucm.cisco.com

Comments
patrickscully
Beginner

Hello,

Does the call filtering with contact center caveat still apply in newer versions of Call Manager (11.5)?

CSCso91760 shows the affected releases up to 8.5(0) but nothing newer.

It also mentions a request for enhancement that would allow an admin to configure which CSS CUCM should use instead of the original device's CSS.

 

thanks.
Patrick

voip7372
Enthusiast

Hi.  Sorry if this has been asked already, but does this process end up breaking the option to block anonymous calls on the DN using the 'Reject Anonymous Calls' on the directory number page?

We're using this setup to be able to block incoming calls based on the calling party number and that works great, but we have a person that keeps getting tons of spam calls from an anonymous caller and we can't seem to stop these calls using the option on the directory number page for this person.  

 

Reject Anonymous Calls - DN.jpg

jmbabcock
Beginner

Hello, just wondering if anyone is still monitoring this thread for questions for this config?

 

tks

dakeller
Cisco Employee

Jeremy, 

Yes, I am still monitoring and responding to feedback from folks reviewing and using this call flow.

Thanks, 

Dan

jlehner11
Beginner

Thanks for the great info.  I do have a question as we have a bit of an odd setup and want to make sure this will actually work for us.  

 

So we still use 4 digit extensions/DN's for most internal devices our users call from and those reside in an Allphone-PT.  

In addition we have some DN's setup that are in no partition and some in a 10-digit partition for any 10 digit number in our system like fax numbers or ccx triggers that go to our contact center for example, and some setup for CER use that are in a CER-911-PT. 

 

We have CTI route points to unity call handlers in our Allphone-PT

We have CCX triggers - in a 10 digit PT as mentioned above

Route points that route to unity and or CCX  that have no partition

CTI ports for CER with - no partition

Route patterns to 10 digit fax numbers which are part of 10-digit PT

And have translation patterns for our DIDs that are in the 10 digit PT as well.

 

So to allow the 10 digit numbers and 4 digit internal numbers to work properly (10 digit numbers were put in their own partition to prevent any overlap) we have a Gateway-CSS that has already been setup and applied to the gateways inbound calls section in CUCM.  The problem is for that to work currently the Gateway-CSS has the 10-digit-PT and the Allphone-PT already applied to it.  

 

It is my understanding that if we apply the steps in your document we will be running into issues with the inbound calls and possibly with the routing of calls through CER like for PSAP callback, CCX, or call handlers. etc.  1.  We have a gateway-css setup that has basically all our DN's in it already.    

 

New to managing Cisco phone system and having a hard time trying to wrap my head around how to make this work properly.  Initially looking at things it feels like it may require some rework of current setup.  Any suggestions would be helpful!  Thanks in advance!

 

 

 

Crissa_Toma
Beginner

Hello, 

Thank you for this document. We used it and it helped a lot. 

With a tiny mention - for All other calls will route pattern, we had to use "/+!", because the configuration with "!" blocked the international calls starting with "+" (CUCM rejected the calls with "404 Not Found"). 

Regards,

Cristina

voelkers
Beginner

Hello! I am very much a beginner with Cisco Unified CM Admin. I tried following these steps, but must be doing something wrong. I created a ! translation pattern in the Inbound_Calls Partition, but then I couldn't create another ! translation pattern for the Filter_List partition, it set itself to a 1 instead. 

I also have no idea how to complete step 9..... I don't know what "an ingress gateway that will be blocking inbound calls based on calling party identification (H323, MGCP or SIP trunk)" is. Sorry for my lack of knowledge, but if you have any advice I will gladly take it!

voip7372
Enthusiast

voelkers:

I ended up not using the setup mentioned at the top of this discussion.  I did use it at first, but I eventually ran into problems with the script in CUCM working correctly and I had people complaining that inbound calls with no caller-ID (anonymous) were failing.  I tried to edit the script to insert +00000000000 and that worked for awhile too (it was no longer an 'anonymous' call, it was a call from +00000000000) but that ended up having trouble later on.  The script seemed buggy.  So, I went a more simple and easy route.  I'll try to paste in my notes on how I configured this in my Cisco CUBE router and CUCM (11.5).  Hope it's clear enough. 

Basically, what I did was add some entries in the router where the phone company's calls come to us and that entry is intended to change the 'From' SIP header if it has 'anonymous' in the header.  I change anonymous to +00000000000.  The CUCM user that receives the call will see all 0s, which would be obvious to them that the call is anonymous.  Once the call is at CUCM, I can easily allow those +00000000000 calls to pass through and call the user (and allow any other call with a valid name and number) and I can also still block specific numbers.  Keep in mind, I'm using +E1.64 format numbers in CUCM so that's what my notes are based on.

In my CUBE router...

Enable inbound SIP Profiles option in CUBE Router:
voice service voip
 sip
    sip-profiles inbound
 
Add a new SIP profile  and add an entry to catch the incoming anonymous calls (profile 2 was next available in my case):
voice class sip-profiles 2
 request ANY sip-header From modify "<sip:anonymous@" "<sip:+00000000000@"
 
Add the new inbound SIP profile to the incoming dial perer (if you're setup this way):
dial-peer voice 100 voip
 description INCOMING CALLS FROM TELCO
 session protocol sipv2
 session transport udp
 incoming called-number +T
 voice-class codec 1
 voice-class sip profiles 2 inbound
 voice-class sip bind control source-interface GigabitEthernet0/0/1
 voice-class sip bind media source-interface GigabitEthernet0/0/1
 dtmf-relay rtp-nte
 dtmf-interworking standard
 fax-relay sg3-to-g3
 fax rate 14400
 no vad

 

Next, in CUCM (your CSS/Partition setup may vary, but this is how I did it):

See image/screenshot for setup below.  I hope you can click to expand it.

incoming-calls.jpg

Create
Recognize Your Peers
Content for Community-Ad