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

Blocking Calls Based on Calling Party ID

166736
Views
150
Helpful
149
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.
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

 

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.

 

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
Beginner

Hi,

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

Thx!

Cisco Employee

Kasiraman,

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. 

Thanks,

Dan Keller

Technical Marketing Engineer

Beginner

Hi,

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,

Erik

Cisco Employee

Erik,

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.

Thanks,

Dan Keller

Technical Marketing Engineer

Enthusiast

Hi,

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. 

Cisco Employee

Troy,

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.

Thasnks,

Dan Keller

Technical Marketing Engineer

Enthusiast

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!

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.

Beginner

Hi,

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!

Cisco Employee

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. 

Thanks,

Dan Keller

Technical Marketing Engineer

Beginner

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

Bryant

Systems Support Engineer

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!

Cisco Employee

Christopher,

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. 

Thanks,

Dan Keller

Technical Marketing Engineer

Dan,

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.

Cisco Employee

Christopher,

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.

Thanks,

Dan Keller

Technical Marketing Engineer

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards