The approach described in this blog is focused on filtering calls based on CPN as presented from the PSTN (via a voice gateway or CUBE). It does not address “black listing” for Cisco Mobility or other station-to-station or stations-to-PSTN use cases.
A typical use case is to block marketing calls, recruitment calls, or any other call that is generally unwanted. The idea is that the administrator creates a list of CPNs that should be blocked and anything else is permitted. Truly a basic concept.
Prior to CUCM 8.0, the most common method for black listing unknown inbound calls based on CPN was to leverage translation-profiles on a Cisco IOS gateway. With the release of CUCM 8.0, there is another option made available to administrators that I believe improves overall operational sustainability.
The Translation-Profile Method
The following diagram illustrates the basics of this method.
In the above example, a call is presented to the voice gateway by the PSTN. The gateway leverages a translation-profile on an ingress POTS dial-peer to “test” the CPN against a list of “blocked” numbers. If the CPN is in the block list then the call is rejected using an administratively defined message. If the CPN is not blocked, then the voice gateway will continue processing the call, matching the VoIP leg dial-peer, and all is well in the world.
An example configuration supporting the described call flow could be:
!Voice Translation Rule set
voice translation-rule 69
rule 1 reject /^800.*/
rule 2 reject /2025551000/
rule 3 reject /7035551000/
!Voice Translation Profile Assignment
voice translation-profile all-blacklist
translate calling 69
! Sample POTS Dial-Peer
dial-peer voice 39001 pots
description Ingress From PSTN
incoming called-number 301555....
call-block translation-profile incoming all-blacklist
call-block disconnect-cause incoming call-reject
The POTS dial-peer 39001 is handling ingress calls from the PSTN and it is configured to check the ISDN call setup information elements (IE) against a translation-profile to determine if the call is permitted. The translation profile “all-blacklist” identifies the translation-rule and the IE that should be evaluated. Specifically, the calling IE.
Translation rule “69” defines several patterns that should be rejected. Namely, any number that begins 800, calls from 2025551000, and calls from 7035551000.
The method just described is only applicable to SIP and H.323 configurations. It does not work with MGCP. An additional point of interest is that there is a limit of 15 rules in a translation-rule set. Fortunately, I have not ran up against this limit but I suspect that some people have.
CUCM Route Next Hop by Calling Party Number
In CUCM version 8.0, Cisco added the Hotline Feature. One configuration element added to support this feature is a new paramter on Translation Patterns. This new parameter may be used to instruct the CUCM digit analysis routine to evaluate the call by CPN rather than called party number (DNIS). This configuration parameter is called “Route Next Hop by Calling Party Number” and it can be used to facilitate “black listing” CPNs without requiring the administrator to use the Hotline Feature.
The following diagram illustrates a sample call flow where CPN filtering is facilitated by this new capability.
The call flow can be described as follows:
- The PSTN carrier presents the call to the voice gateway.
- The voice gateway processes the call and then relays call setup information to the CUCM.
- The gateway object in CUCM is configured to use CL_PSTN-In_CSS, which is used for the initial digit analysis step.
- A translation pattern in CL_PSTN-In_PT route partition is configured to capture any CPN by using the “!” digit pattern
- Translation Pattern: !
- Partition: CL_PSTN-In_PT
- Calling Search Space: CL_PSTN-Screen_CSS
- Route Option: Route this pattern
- Route Option: Urgent Priority
- Route Option: Route Next Hop by Calling Party Number
- Assuming that a CPN is present, CUCM will continue digit analysis using CL_PSTN-Screen_CSS.
- The CL_PSTN-Screen_CSS contains one partition, CL_PSTN-Screen_PT and this partition will contain allow and deny patterns. This is where the magic happens.
Before going into how we want to leverage CL_PSTN-Screen_PT, I want to point out something about what is happening at Step 4. I tried this configuration a few times in my lab without success and I realized two things. First, I need to work on my reading comprehension skills. Second, the term “Route Next Hop by Calling Party Number” should be read literally.
What is happening here is that the “!” pattern in CL_PSTN-In_PT is telling the CUCM “evaluate the CPN against the patterns in CL_PSTN-Screen_CSS”. Originally, I was trying to add my blocking patterns to CL_PSTN-In_PT with the “Route Next Hop” flag and the “Block this pattern” flag set on the same pattern. This does not work.
Instead, what you need to do is create translation patterns in CL_PSTN-Screen_PT that are configured as normal translation patterns (i.e. do not check the “Route Next Hop by Calling Party Number” option). What the CUCM digit analysis process is going to do is take the CPN and compare it with the translation pattern(s) in CL_PSTN-Screen_PT.
Continuing our example, as you can see in the figure, we have defined the following translation patterns in CL_PSTN-Screen_PT:
- “!”: This pattern is essentially our explicit “allow all” pattern and the Route Option flag is set to “Route this Pattern”. You need this to allow call setup to continue for patterns you want to allow through.
- The following patterns are configured with the Route Option flag “Block this pattern”. So, calls from a CPN that matches any of these patterns is blocked:
- “2025551000”: Specific pattern match.
- “800!”: Any CPN that starts with 1800 or 800 is matched.
When blocking a pattern, the administrator can select one of several disconnect cause codes to send back to the PSTN carrier (via the voice gateway). Selecting “Call Rejected” may be the preferred option because is the system originating the call is automated (i.e. a marketing company’s predictive dialer) then there is a possibility the system will act on the rejected inform message and remove the DNIS from their dialing target table.
Summary of Configuration Steps
In my lab, I used the following configuration procedures.
- Create partitions:
- CL_PSTN-In_PT: This partition will hold the translations which flag “Route Next Hop” behavior.
- CL_PSTN-Screen_PT: This partition will hold translations used to evaluate CPN.
- Create Calling Search Spaces:
- CL_PSTN-In_CSS: This is the CSS assigned to the voice gateway and it contains the CL_PSTN-In_PT.
- CL_PSTN-Screen_CSS: This is the CSS assigned to the patterns in CL_PSTN-In_PT. This CSS contains the CL_PSTN-Screen_PT.
- CL_Tenant-Control_CSS: This CSS is assigned to patterns in CL_PSTN-Screen_PT and it contains partitions that have phone DNs and other patterns that route to devices or applications on the CUCM cluster.
- Assign the CL_PSTN-In_CSS to the voice gateway.
- Add the “Route Next Hop” translation “!” to CL_PSTN-In_PT. Select the CL_PSTN-Screen_CSS, enable call routing, and enable “Route Next Hop by Calling Party Number”. NOTE: You can also apply calling or called party transformations at this step, as needed.
- Add the “allow all” translation “!” to CL_PSTN-Screen_CSS, enable call routing, and DO NOT enable “Route Next Hop by Calling Party Number”.
- Add any “black list” translation. Enable call blocking, select disconnect cause reason, and you are good to go.
I am not sure why Cisco opted to use a “next instruction” approach here. I am sure there is a good reason and it is probably related to how the Hotline feature is designed to operate. I did try to mix translations that were routing on called party and translations that had the “route next hop” option enabled. Thus, removing one of the prescribed steps. This doesn’t work as one would hope. In my tests, the CUCM digit analysis always preferred routing by called party information if you mix patterns in the same CSS.
The configuration examples provided assume that the calls coming into the CUCM are presenting a valid CPN. If calls coming into the system are flagged as private then CPN is not provided. The pattern “!” won’t help you and you may need to look at using a null (blank) pattern in CL_PSTN-In_PT and CL_PSTN-Screen_PT. (I have not tested this.)
I am still working through running the CUCM approach described in this blog through some of our production design scenarios for validation purposes. Thus far, the approach seems viable for those who use MGCP gateways, would like to centralize call routing on the CUCM, or have ran into limits with the number of rules that can be assigned to a translation-rule set in IOS.
William Bell is the Collaboration Practice Lead for Chesapeake NetCraftsmen. Bill has over 10 years of experience in the IT industry with a focus on communication and collaboration technologies. In addition to blogging on the NetCraftsmen site, Bill also maintains the UC Guerrilla blog: http://ucguerrilla.com. You can follow Bill on Twitter: @ucguerrilla
23 responses to “Cisco CUCM Blocking Calls by Calling Party Number (ID)”
This is very interesting
Hi William, this post was very useful to me. Your posts have a technical explanation easy to understand ;D, thank you for share.
I am glad it was helpful. Thanks for reading!
Thanks for putting your effort writing these helpful posts.
Really excellent information. Very helpful to me.;D
Excellent and helpful information, i have just configured this in a client and seems to be working properly. Can you figure out any simple way to track/log the occurrences of rejected calls? CART?
As you said, someone will face this problem. Do you know, is there any method to block more than 15 numbers? I hope you do))
I have not had to go beyond the 15 but I have fielded this question before. One of the first things to look at is to see if you can use masking on existing patterns to shrink the rule list. The second option would be to work with the carrier to black list the numbers. This may be a logistical hurdle but certainly viable if the carrier is willing to assist. The third option is to upgrade to a version of UCM that supports hotline. I’ll guess that this option isn’t your preferred choice (otherwise, you wouldn’t have to ask the question).
Outside of those options I don’t have a tested solution for you. At one point I went through the thought exercise of using ‘answer-address’ on pots dial peers as one possible solution. There are problems with this approach and I never got to the point where I tested whether these problems can be navigated cleanly. You have to be very careful when using answer-address and you need to understand dial-peer selection thoroughly. So, I concluded that this method was not viable at the time.
Sorry, don’t have any other ideas at the present moment.
Thank you very much, William! We will try to use VoiceISP resources for this.
Hi William, good solution for CUCM, but what happen if the calling number from Voice Gate have this value calling number —N/A— ? Is not be work, because the match is empty, this calls to be Restrict. Do you have idea how decide it?
hi this is
a am also unfied communication engineer want to share if needed
Hi William that works brilliantly EXCEPT I had a problem when the originating call withheld their caller ID then the call failed even with a ! in the translation pattern. Any ideas? I’ve yet to have a play around but its on a production system so I have to be careful.
To capture a null pattern you will need to add a translation that allows the call through and the translation pattern is (blank). Meaning, no digits. Of course, I am assuming that you have already passed the call setup request through the RNH translation before evaluating the (blank) pattern.
Hi Bill, Thanks for the reply. Already tried that. I have tried it with a ! and blank pattern in both partitions. More investigation required when there no t much traffic.
Hi Bill, Yes I tried that with no success. The CLID is of course coming through the CUBE as Anonymous. I am using SIP as the signalling protocol.
Understood. I picked up the thread on the support forum. That is probably a better venue!
Have you an update about both issues :
– Not working with "calling number —N/A—"
– Not working with "caller ID" set
I have tired it today with CUBEs coming in. works very well when CLIs are presented can block or allow. But having issue with with-held numbers/unknown CLIs. such calls are dropped and the Blank TP is not forwarding them.
I tried this out but could only make it work for one destination number which I had to place into "Called Party Transformation" in the Translation Pattern for an OK incoming call. Ideas?
I tried it and it works but only if I setup one destination number in the Called Party Transformations in the Translation Pattern for the valid calls. Ideas?
I am working with CUCM 10.5, you had mentioned "Hotline", can I use that feature or is the process you clearly explain above back in 2011 the prefered method?
Thanks for your support.
I have blocked calls trough config changes on gateway. Works well. I am wondering whether there is a simple way to track/log the occurrences of rejected calls.
Thanks so much …your post are really awesome !!! :D:D:D:D