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

Blocking Calls Based on Calling Party ID

212868
Views
170
Helpful
156
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
almurtad
Community Member

Hello Kaushik, for the "Reject Anonymous Calls" option under the DN or SIP Trunk profile... this will tell CUCM to reject any anonymous calls with caller ID blocked. Blocked caller ID will have the words "anonymous", "restricted" or "unavailable" in the different From: headers (PPI, PAI, RPID or FROM).

 

I hope that helps.

 

Regards,

-Ali Murtada

Cisco ACE

Kaushik Ray
Beginner

Thanks Dan for your views on this.

Kaushik Ray
Beginner

Thanks Ali

dakeller
Cisco Employee

The Anonymous Call Rejection (ACR) feature was released in UCM v9.0.  The ACR feature was to allow an administrator to allow or reject 'anonymous' calls at a device's line level or at a trunk level.  In reviewing the feature implementation, it will capture quite a few of the anonymous call scenario's, but most customers that use the app note are interested in blocking specific caller ID's, which the ACR feature will not be able to accomplish.  

The discussion about passing or blocking anonymous calls on a SIP trunk in this app note is indeed a side effect of the call flow and digit analysis. 

If you purely want to stop anonymous calls from reaching your users, then use the Anonymous Call Rejection feature. But if you need a generic call blocking configuration, then this application note will solve that issue.

Thanks, 

Dan Keller

Technical Marketing Engineer

dakeller
Cisco Employee

After researching the problem reported in 11.0.1.10000-10, I found that the development team 'fixed' a defect that did client side translation validation that is causing the issue seen.  There were a number of leading characters that are prohibited, but the DE included ! as one of those.  I verified that ! is a valid pattern for a translation (via the data dictionary) and have submitted a high priority defect to get it fixed.  

I will update this thread again once the defect is fixed and what release it's safe to upgrade to.

 

Thanks, 
Dan Keller
Technical Marketing Engineer

Gerson Fabian Morales Marin
Community Member

Hello all,

 

I would like to add something to your document; I have been working on case and I was able to find that sometimes when globalization is being used and the CSS is applied to the GW this configuration will block all calls to internal lines unless you add a translation patter such such the following:

Pattern=\+!
Partition=Filter_List_PT
CSS=43-BTR40-PSTN-IN_CSS (Internal-DNs)

 

From traces you can see the following:

 

20:06:37.052 |Cdcc::preliminaryProcessCcSetupInd(0000073): precLvl=5|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |Digit Analysis: star_DaReq: daReq.partitionSearchSpace(6d1dbe9c-2a1e-8b56-093e-50e17bfd88bb), filteredPartitionSearchSpaceString(InboundCalls_PT), partitionSearchSpaceString(InboundCalls_PT)|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |Digit Analysis: star_DaReq: Matching Legacy Numeric, digits=43xxxx|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |Digit analysis: match(pi="2",fqcn="", cn="+1610850xxxx", plv="5", pss="InboundCalls_PT", TodFilteredPss="InboundCalls_PT", dd="434414",dac="1")|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |Digit analysis: potentialMatches=NoPotentialMatchesExist|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |EnvProcessCdr::wait_DbCdrReq|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |EnvProcessCdr::wait_DbCdrReq DETAILED Entries 53, Inserts 44,             ZeroCalls 9, StartRecords 0, Default 0|2,100,160,1.283^172.20.97.254^*
20:06:37.052 |EnvProcessCdr::openNewCdrFile|2,100,160,1.283^172.20.97.254^*
20:06:37.053 |MGCPBhHandler - Sending BhHdr: 0004 0000 0010 8000 0001 0009
|2,100,160,1.283^172.20.97.254^*

 

At the end the configuration should be like the following:

 

Translation pattern #1
!
PT= InboundCalls_PT
CSS=To_filter_List_CSS
{X}Route Next Hop By Calling Party Number
----------------------------

Translation pattern #2
!
PT=Filter_List_PT
CSS=PSTN-IN_CSS (This css has access to all internal lines, it is the original CSS that customer had on the incoming setup on the gateway.)
-----------------------------

Translation pattern #3
Blank for numbers without calling ID.
PT=Filter_List_PT
CSS=-PSTN-IN_CSS (This css has access to all internal lines, it is the original CSS that customer had on the incoming setup on the gateway.)
-----------------------------
Translation pattern #4
1225405xxxx (Number that I need to block)
PT=Filter_List_PT
CSS= NONE
{X}Block this pattern =Unallocated number.
-----------------------------

Translation pattern #5
Pattern=\+!
Partition=Filter_List_PT
CSS=PSTN-IN_CSS

 

Regards,

Gerson (gersomor)

 

 

hello IAN 

I did the same, i mean, for routing calls to specific gateways instead of using it for blocking. my issue is with the forward condition. ANI is being replaced by the previous called extension. ANI should be the extension that is forwarding the call to another number. so for this cenario the calls fails because it is trying to egress the wrong gateway (calling user GW not the forwarder GW). do you get it? did you have this issue?

thanks !

dakeller
Cisco Employee

Henrique, 

There are a few settings that could make this behave the way you describe.   UCM has the ability to select the which calling party is used as it's routed through the system.  But based on what you are describing, xlate patterns do not let you choose the which field to look at.  So without control on which field you use for the 'route next hop by Calling Party Number', you will be limited.

For the fowarding situation you are describing, I am not sure there is a way that you can modify that behavior.  Sorry, but this is a situation that I will not be able to solve due to the way forwarding works and the source call routing method that is being used to select the route (GW).

Thanks, 

Dan Keller

Technical Marketing Engineer

dakeller
Cisco Employee

Ian, 

What you described is behaving as expected.  You need the first xlate to do the source call routing by sending all calls the the next call processing step to use the 'Route Next hop by Calling Party Number'.  That will allow you to select the path for the call based on calling party, but if you actually select the next route (i.e using a route pattern), you are stuck with the calling party being used as the called party, which is not what you want. 

But by using xlate patterns to match the calling party number to then select the gateway, after the xlate pattern has completed it's route based on calling party number, the next call route decision will revert to use the original called party number.  You had to route to a Gateway/route pattern through the xlate with out using a route pattern as the selection criteria for call routing.

Make sense?

Thanks, 

Dan Keller

Technical Marketing Engineer

thanks for your reply. So I guess I will have to create specific routes for forwarding conditions.

IT Department
Beginner

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
Contributor

Question.

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.

dakeller
Cisco Employee

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 script....to 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.

Thanks, 

Dan Keller

Technical Marketing Engineer

IT Department
Beginner

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

Mike, 

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.

Thanks, 
Dan Keller
Technical Marketing Engineer