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

Blocking Calls Based on Calling Party ID

214411
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
dakeller
Cisco Employee

unfortunately, the script must be applied to the incoming trunk if you want to block calls. Although UCM allows LUA scripts to be applied to SIP UA devices (aka the phones), by the time you reach the LUA script for a UA, you're past the digit analysis that would allow you to block the call.  You could use a LUA script to affect what gets displayed on the phone for an anonymous call, but you will not be able to use the LUA script to block calls to an endpoint.  

Thanks, 

Dan Keller

Technical Marketing Engineer.

ksheth001
Beginner

Got it, thank you.

Hi,

Great doc. Thanks. I'm wondering would it help me with an issue i have. 

I have a multi cluster setup. All users across three cluster can call each other as normal. I need to restrict call forward off net in certain cases. 

Phone A on Cluster A has CFNA both internal and external set to call his mobile. If Phone A receives a call from PSTN or any other phone on cluster A the call can forwarded as required. 

If Phone A receives a call from Phone B on Cluster B or Phone C on Cluster C the call can not be allowed to call out to the PSTN (No forward to mobile or any other external number). 

I'm wonder would the above work in this scenario as we would be dealing with redirected calls. 

Any input would be appreciated. 

dakeller
Cisco Employee

Michael, 

Unfortunately, this script/call flow is not applicable to what you want to do. Also, if you want some calls over the ICT to have access to the PSTN and other to not have access, that is going to be very difficult to accomplish.  What you are describing sounds like the TRAI regulations in India.  We can prevent some calls from other clusters from going out, but it would involve the use of Geolocations and Geolocation Policy.  I would recommend looking into that feature because that does allow you to specify restricted call flows similar to what you're asking for in your query.

Thanks,

Dan Keller

Technical Marketing Engineer

derveniss
Beginner

I have a CUCM 8.6 running MGCP and i also use time-based routing.

I did exactly what your documentation describes and made some test calls.

I have two issues.

1. When I call from a "blocked" number I dont get a Call Reject tone (as i have configured) but it seems that it rings. That's not a critical problem because the feature works. Not ideally but it's ok.

2. In the non-working hours normally i forward all incoming calls in an auto-attendant.

Now all incoming calls drops. Both from blocked and non-blocked numbers. In my gateway i get  "Cause i = 0x8091 - User busy".

 

Any ideas?

 

Thanks, Spyros

dashoward
Beginner

Hi All,

This document seems to be ageless. Anyone run into the issue with an 11.5 SU2? I've followed the steps to a Tee.  However when I get to step 5 and apply the "Filter to List" CSS and I check the "Route Next Hop By Calling Party Number" box ALL of my calls get blocked. I implemented the steps one by one so to ensure when I know I broke something. When I apply the CSS calls fail and when I check the box call continue to fail. I've complete steps 6, 8, and 9 however no dice.  Does anyone understand why my incoming calls are failing?  Below is what I have with minor verbage change.

 

PSTN Incoming PT

PSTN Filter List

=======================

Insert PSTN Incoming PT ==> Gateways CSS (only partition in gateway CSS)

Filter List PT ==> To Filter List CSS

=======================

Translation pattern I've tried both my existing 3XXX and ! ==>PSTN Incoming PT ==>To Filter List CSS

Check "Route Next Hop By Calling Party Number"

========================

Transalation patter again with both my existing 3XXX and ! ==> Filter List PT ==> Internal CSS

========================

Apply Gateways CSS to Inbout CSS, Reset the GWs...

 

No Dice!

 

Any Clues????

adamperkins1
Beginner
Anyone run through this with positive results when call blocking in a SME (using these steps), when ILS is in use? Struggling with getting this to work mainly with ILS. It will work with static routes per say, but if a number is learned via ILS, even if your calling number is in the block PT, it still routes to said ILS number... Anyone done this? Thank you in advance.
dineshshoba
Beginner

 I have blocked a specific pattern in my cucm 11.x. But the anonymous calls are getting rejected. Created a NONE translation pattern but it doesnt work. I am having a MGCP gateway. Other options i have read to uncheck the (reject anonymous call in the DN option) box. But all the DN's are unchecked already. Any other solution to convert a anonymous call to a generic call so that cucm will accept the calls.

adamperkins1
Beginner

In my case, Cisco opened a bug ID regarding ILS and GDPR use with Call Filtering. That bug ID is CSCvg77238. I was using SIP in my scenario, but for anonymous calls to come through properly you also need to do some translation work on the gateway itself (voice class sip-profile), or in CUCM with a normalization script applied to the gateway.

randall66
Beginner
I am using this setup without a hitch except for one location, when it is enabled it blocks some called numbers from a non blocked calling number. I call with my cell phone (non blocked number) and I call the main number it gets blocked, if I call another number from the same cell it works. Really confused why it is doing this.. Any help...
jay.johnson1
Beginner
Dan, do you still watch this thread?
jay.johnson1
Beginner

@randall66: Randall, I still am not able to get this working; which "partitions" and "calling search spaces" are your phones and route patterns using once you are finished with the above configuration DKeller made available to everyone? I "think" that's part of the confusion some of us are experiencing... After all the above information is presented, it "IS NOT" clarified whether "EXISTING PARTITIONS/CALLING SEARCH SPACES" used by the internal numbers need to be changed to the new partitions in order for call blocking to work. Can someone clarify this please? Thanks... Jay

jay.johnson1
Beginner

To anyone who is still following this thread, HOW ARE YOU GETTING YOUR CALLS "OFF" OF THE PSTN AND "INTO" YOUR CUCM ENVIRONMENT?

 

I haven't seen this addressed by anyone; I'm attempting to bring my calls "in" from the PSTN through an FXO port on my cisco 2921 router with the following configuration on the FXO port:

voice-port 0/1/0

connection plar opx 5088

caller-id enable type 1

 

Here is the configuration on my internal dial-peer that's pointing to my call manager:

dial-peer voice 3 voip

destination-pattern [2-9]...$

session target ipv4:172.16.3.160

dtmf-relay h245-alphanumeric rtp-nte

 

On my CUCM, I'm using the "Gateway" option under the "Devices" menu. After following the above article, no matter what I do, my calls "are not" being blocked, to include my even trying to block the calls directly on the voice gateway. How are the rest of you configured so as to be able to block calls? Jay

jay.johnson1
Beginner
To anyone who is still following this thread, HOW ARE YOU GETTING YOUR CALLS "OFF" OF THE PSTN AND "INTO" YOUR CUCM ENVIRONMENT?
I haven't seen this addressed by anyone; I'm attempting to bring my calls "in" from the PSTN through an FXO port on my cisco 2921 router with the following configuration on the FXO port:
voice-port 0/1/0
connection plar opx 5088
caller-id enable type 1
Here is the configuration on my internal dial-peer that's pointing to my call manager:
dial-peer voice 3 voip
destination-pattern [2-9]...$
session target ipv4:172.16.3.160
dtmf-relay h245-alphanumeric rtp-nte
On my CUCM, I'm using the "Gateway" option under the "Devices" menu. After following the above article, no matter what I do, my calls "are not" being blocked, to include my even trying to block the calls directly on the voice gateway. How are the rest of you configured so as to be able to block calls? Jay
dakeller
Cisco Employee

To Jay's query above.  Dan Keller is still monitoring this app note and responding to questions.  It looks like I have not been getting notifications of postings on this app note, that is why I have not responded in a while to any posts.

Thanks, 

Dan Keller

Technical Marketing Engineer

Cisco System