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

Blocking Calls Based on Calling Party ID

164550
Views
145
Helpful
147
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
Cisco Employee

Christopher, 

Long story short, the answer is no.  Because the manner in which Cisco does call blocking, the calling party identifier must be passed into digit analysis as a number (not a URI or string).  

 

Thanks, 

Dan Keller
Technical Marketing Engineer

Thank you Dan, we don't have any PSTN SIP trunks that we have to worry about blocking anonymous calls.  We are using just the very basic call blocking you describe in the call flow above. 

We moved our MCGP trunks to the new cluster, which were built by hand, not imported or migrated from the other cluster.  They were built just like the other cluster.  We're 65% through a migration, and we have 95% of our end devices sitting on our 8.6 cluster.  The 2 clusters are tied together with a SIP trunk.  Incoming calls will come in the PRI's and most calls will flow across the SIP to the 8.6 cluster.  Some calls will flow to end devices on the 10.5 cluster. 

I'm pretty new to Call Manager, but not telephony and voice switching, so I'm having a difficult time trying to "translate" between the 2.  So I apologize if I sound green, it's because I am.  I'm pretty sure my problem lies in a CSS/Partition snafu somewhere between the SIP/PRI/Phones on the 10.5 cluster. 

 

 

Cisco Employee

Matt, 

hard for me to say what's wrong.  If everything is getting blocked, it sounds like the patterns in the filter partition are not working as expected.  The filter partition needs to contain the calling party numbers you want to block as well as a generic route pattern ! and a NULL translation.  If the inbound calls are hitting a generic ! pattern with the 'route next hop on calling party' with a CSS that has the filter partition, then you need to look at your translation patterns in the filter partition.  

Thanks

Dan

Beginner

Thank you very much. Your anonymous script saved us after a 7 hour, priority 2, TAC call.

We are running CUCM 10.5.2 and just switched from PRI lines to SIP trunking. Anonymous calls with Remote-Party-ID or P-Asserted-Identity worked, but we were losing the rest.

Good job.

Frequent Contributor

I had to add the following after the modifyHeader step in the lua script to remove the P-Asserted-Identity header on Anonymous calls in an environment I was working in. It only removes PAI if the header is present.

msg:removeHeader("P-Asserted-Identity")

 

This was on a 9.1.2 CUCM system.

Cisco Employee

Erick,

Thanks for the feedback.  I have responded to your off line, but for this posting, I will confirm that the LUA script does not include a PAID check.  I have a newer version of the script that is more generic and includes support for UCM v8.5 to v10.5.  I will post it shortly.

 

Thanks, 

Dan Keller

Technical Marketing Engineer

Cisco Employee

After much field testing, I have updated the LUA script to be used for anonymous call blocking.   The new script will change the 'anonymous', 'restricted' or 'unavailable' calling party with a <NULL> field. The benefit of this change is that now you can allow or deny the call based on a <NULL> translation in the Filter_List partition.  A side benefit to the new script is that the display on the phone for allowed anonymous calls in most cases will be 'private'.  End users expect that a call from an unknown caller to show as private, so this user experience is more in line with end user expectations.  

If you encounter any problems with the script not behaving correctly, please follow the instruction in the script to get support.  TAC support for this script is 'best effort', so if TAC cannot solve the problem, I can.  

Thanks, 

Dan Keller

Technical Marketing Engineer

Enthusiast

Awesome!  Thanks so much Dan for all your excellent work on this!

Contributor

I attempted this in CUCM 8.5.1.13900-5 with no luck. Seems any Enterprise level customer this won't work;

  1. CTI Redirects not working (Attendant Console, UCCX, and Emergency Responder) just as others in the comments noted :)
  2. Globalization under Device > Gateway (puts that +1 for National, + for Intl calls, etc in the Missed Calls, Placed Calls, Received Calls in the Directory for easy callback) causes Digit Analysis to fail in 8.5.1.13900-5

 

I stayed with our old-school solution; but it's can't store enough numbers. Will the number of IOS translation-rules be increased in a future release beyond 100?  Is there already a PERS request to increase the number beyond 100?

voice translation-rule 777

rule 1 reject /^6166132291/
rule 2 reject /^6169802150/

!
voice translation-profile blockedNumbers
translate calling 777

dial-peer voice 1 pots
trunkgroup PRI
call-block translation-profile incoming blockedNumbers
incoming called-number .
direct-inward-dial
!

TAC SR 634192979 has traces attached.

Enthusiast

I realize this doc is a litte aged but assuming the setup is still the same in Ver 9.1.2

 

Great simple instructions, +5

 

I set up exactly as specified, and when i do a gateway analysis it show the call (from my cel ) being blocked, however in function it rings.  Tried with several different numbers just to make sure werent typo in the Translation Pattern to block.

 

Any gotcha's that werent noted in the orignal article that i can look for?

thx

Participant

I can't speak to your specific setup, but can tell you I use 9.1.2 and have this working as designed with the anonymous script applied to the SIP trunk to permit unknown callers.  I haven't referred to this document in quite a while since getting it configured correctly and sorry if this is stating the obvious, but since you mentioned the analysis works, I would suggest making sure you've reset the involved gateways/trunks before testing live.  It will not take effect without doing so, which will drop active calls.

Beginner

Dan,

There are many forum links to this blocking function that state this can be used as a means to "source route calls" by the Calling Number.....towards specific gateways/destinations.

My testing has found that instead of blocking the pattern, you direct it via a dedicated CSS to a Route-List/Route-Group........but the calling number is then transposed as the Called Number. So it doesn't work. The calling number and the called number are then the same......no good.

Has anyone been able to use this "blocking method" to successfully do routing via the calling party.......to specific gateways etc.

 

Regards,

Ian.

 

Beginner

Dan,

Just as an update for interested parties........I was using Route Patterns in the "filter" logic......instead of Translation patterns. When I corrected this, the routing is working correctly. The Calling number is no longer transposed to the called number.....and using specific CSS I can offnet calls via any gateway/resource based on the calling number pattern..

Very pleased this works.

Thank you for all the documented steps you have tested and provided.

Regards,

Ian.

 

Cisco Employee

I regularly test this call flow and script on newer versions of UCM to make sure it works.  I just completed testing on 11.0(1) and it works same as it does on all the other versions that I have tested.  The version I have verified this on include 10.5(x), 10.(0), 9.1(x), 9.0(x), 8.6(x), 8.5(x).  

 

Thanks, 

Dan Keller

Technical Marketing Engineer

Cisco Employee

To all, I recently had another variation on the anonymous caller that I wanted to let the community know how to fix.  The scenario was the inbound INVITE from the SBC was blindly adding +1 to the calling party number.  When the SIP trunk got the INVITE, the from value was "sip:+1anonymous".  

The anonymous script looks for "sip:anonymous", so the +1 was not properly detecting the call was anonymous. Since the prepending was blindly added, changing the script value to look for the +1 provided an easy solution.  

The search value was changed from:

"sip\:anonmyous"

To:

"sip\:%+1anonymous"

 

I'm sure you LUA programmers could solve the problem generically, but this did correct the issue for the customer.

 

Thanks, 

Dan Keller

Technical Marketing Engineer

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