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

Blocking Calls Based on Calling Party ID

224193
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
jjia
Beginner

Is there any way to block some specific incoming calls to be recorded in CDR?

dakeller
Cisco Employee

The call will be recorded in CDR's even if it's rejected through this method.  You can find calls that are rejected based on the rejection type you have set at the xlate pattern.   But I must warn you that there is no special indication that a call was rejected by this configuration.  So if you set the rejected reason code to something like 'Number changed (one not commonly used in CUCM), then you can look at the CDRs to find that cause code to determine which calls were rejected through this configuration. 

Thanks,

Dan Keller

Technical Marketing Engineer

ALI HYDER
Enthusiast

Dan,

We have a user who is complaining that she is getting harassing calls from a particular caller. My questions is, is it possible to setup translation rule only for this user's extension instead of rule based on Calling party for the entire site?  We are running CUCM 9.1.1, I would like to know if I can match a call based on both a "Calling" and a "Called" party and then allow or reject it?

Thanks

Ali

dakeller
Cisco Employee

Ali,

If you look at the method by which the calls are passed to the xlates that will block the call, I use the ! value.  That means a call to any number matches.  If you want to block for a single person, the ingress GW can have an xlate that matches that person's number that will send the call to the block partion, then you can block it.  So even though you cannot block based on both calling and called party in the same operation, you can accomplish what you want to do relatively easily.

Thanks

Dan Keller

Technical Marketing Engineer

wdgarfield1
Beginner

We are dealing with the Null callerID issue on the gateway router, using a voice translation-rule /^$/ to insert /0000000000/   In this way every call coming into the CUCM has some value appearing in the calling party field, even if it's a string of 10 zeroes. This allows these calls to pass through the callerID blocking without being blocked.

goku-sun
Beginner

Hi dakeller,

May I know the details of workaround for sending a call without calling ID via null translation. I met the same problem and is urgently seeking solution on this.

Many Thanks,

Goku

dakeller
Cisco Employee

Goku,

There is a lot of information missing to be able to answer your question.  What is the protocol into CUCM?  Do you have a Gateway or Trunk?  Are you looking to block NULL caller id's or do you want them to pass?  If you provide the details, I can provide guidance on how to correct the call flow to make this work.

Thanks,

Dan Keller

Technical Marketing Engineer

goku-sun
Beginner

Hi dakeller,

Thanks for your quick response. Please see the background below:

1) An etraIi PBX is interfaced to a new MGCP GW via QSIG links. With other MGCP GWs connected to 2 different Telcos "A" & "B", all under CUCM 8.6. For voice mails, the Etrali phones will access an ext (say "5000") and it directs the call to the CUC 9.X as no answer call fwd or all call fwd, with corresponding ext defined in the CUC.

2) The translations are used identify the calling ID from PBX and route calls to appropriate CSS's towards T1s of telco "A" and telco, say, 2XXX = DDIs of telco "A"; 6XXX = DDIs of telco "B"

3) All are worknig fine now after CPN is set up for all extensions from the PBX. Except that if a call orginates from PSTN, the call will drop after ringing some time if no answer or via call forward to the voice mail extension. If the call originates from another Etrali ext, voice mail can be left. If the translations are not used(then outgoing call from 6XXX will display as prime # of telco "A"), voice mail can be left from PSTN and extensions.  Is there anything altered after transation is done?

Etrali phones (2XXX, 6XXX) <-> Etrali PBX <->  QSIG links <-> Cisco MGCP VG  <->  CUCM <-> Cisco phones / PSTN (other MGCP GWs to different telcos, 8888-2XXX for telco "A", 9999-6XXX for telco "B")

Config (CUCM 8.6.1)

0) A MGCP VG is installed with QSIG links to interface PBX and CUCM, the partition of QSIG link is "PT_Etrali_incoming".  Another partition as "PT_Etrali_Translation". CSS's with "CSS_Etrali_incoming" and "CSS_Etrali_Translation" are created to include the partitions just mentioned respectively

A) A translation pattern defined as "!" with partition = "PT_Etrali_inoming" for the QSIG link of MGCP VG, CSS is "CSS_Etrali_translation". Option "Route Net Hop by Calling Party Number" is also CHECKED

B) 2nd translation = "2XXX", partition = "PT_Etrai_incoming" and CSS = "CSS_Etrali_Telco_A". This to route  2XXX call to Cisco ext or PSTN via telco "A" (to display his CLI to PSTN instead of incorrect prime# or unknown# )

C) 3rd translation = "6XXX", partition = "PT_Etrai_incoming" and CSS = "CSS_Etrali_Telco_B". This to route  6XXX call to Cisco ext or PSTN via telco "B"  (to display his CLI to PSTN instead of incorrect prime# or unknown# )

Many thanks,

Goku

dakeller
Cisco Employee

Goku,

I have read the configuration that you have set up and understand that the issue is calls from the PSTN will drop if the call is CFNA to voice mail.  But one item that is missing is the call flow.  Something like 'call arrives from telcoA, routed to Entrali PBX, CFNA back to CUCM to reach CUC'.  If the flow is like this, then there are 2 potential issues.  The first is that the calling party number is a PSTN number and the Xlate patterns you have for the Entrali trunk don't match to route the call to CUC.  The other choice is that the xlate pattern is matching the external number, but the CSS of the matched xlate does not contain the partition for reaching CUC at 5000.

Thanks,

Dan Keller

Technical Marketing Engineer

Baraa Alhourani
Cisco Employee

Hi Dan,

Thanks for the great document.

My customer runs CUCM version 8.5.1.10000-26. I have completed the steps on his system, after that I was able to block a certain caller but at the same time other callers were blocked.

I have recreated the issue in our lab CUCM version 8.6.2.23045-1 and found that the callers are not hitting the ! TP which is assigned to 'Filter_List' partition unless the prefix for the calling party in the incoming calls is configured.

Please find the attached picture:

if the system was configured as shown in the picture all other IP-Phones which are registered to CUCM 2 will not be able to dia 7070 IP-Phone, but if I configure prefix 6 at the calling party for incoming calls and modified the 8080 TP to be 68080 everything works properly (IP-Pone 8080 is blocked and all other IP-Phones are able to call 7070).

Please let me know why other IP-Phones were not hitting the ! TP ? and how should I proceed? CallBlock.png

ealeatherman
Enthusiast

Greetings,

I was wondering if the version dependencies/inconsistencies are still present in this feature with regards to restricted or anonymous caller id - particularly with CUCM 8.6(2). I'm doing some planning around implementing this blocking capability but I need to be able to permit these types of calls through. It seems based on comments above that there are still potentially some caveats for this.

Thank you for the excellent document and explanations by the way.

Thanks!

Ed

Mathew Varghese
Beginner

In paralle, to achieve blocking feature for a single user, can we perform access restriction in CSS level of Translation Patterns.

ie. for the ! and null TP's, use CSS to all internal extensions

     for blocking TP, route the pattern and put CSS with all internal extension minus the one phone under question !!!

Could not test this setup, appreciate any responses.

-mathew

dakeller
Cisco Employee

Ed,

When referring to dependencies/inconsistencies, the only interface that I saw was different was the SIP Trunks. PRI and H323 behaved the same on both versions.   So the difference between 8.6(x) and 9.0 was the fact that URI dialing was added to call control in 9.x.  This altered how non-numeric addressed were handled and I believe this change was the cause of the inconsistencies that were observed between versions.  I have tested the blocking based on caller ID over SIP trunks in the 8.6(x) version and the 9.x version and have been able to achieve the desired results in both cases. 

Hope that helps.

Thanks,

Dan Keller

Technical Marketing Engineer

dakeller
Cisco Employee

Matthew,

To block calls to a specific user, you can specify the xlate pattern as the destination DN of that user, then send those calls to the block partition, all other calls can go straight to the users.  The point of the ! xlate pattern on inbound is to 1) collect all inbound calls to any number 2) set the 'route next hop by calling party number'.  So the application note was written to send all calls to be filtered.  If you want specific users to have anonymous calls blocked, then the xlate pattern at the GW level should include only those users you want to block calls for.

Hopefully that answers your question.  If not, repost and I will reply.

Thanks,

Dan Keller

Technical Marketing Engineer

jeremiah88
Enthusiast

Great article Dan!  Thanks for the script too, ultimately your script is the only thing I could get to work with SIP PSTN---SIP CUCM...  I tried using a SIP Profile (TAC even wrote it for me):

voice class sip-profiles 100

request ANY sip-header From modify "Anonymous(.*)" "1234567890\1"

request ANY sip-header From modify "anonymous(.*)" "1234567890\1"

request ANY sip-header Remote-Party-ID modify "Anonymous(.*)" "1234567890\1"

request ANY sip-header Remote-Party-ID modify "anonymous(.*)" "1234567890\1"

But since I had routing based on CPN setup in CUCM (as per instructions in this blog), call still would not get through...Finallly, I applied your script, and it worked!

Many thanks!

Create
Recognize Your Peers
Content for Community-Ad