Remote Communications During A Crisis Can Be Challenging – Some Things To Think About
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:
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:
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.
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
Remote Communications During A Crisis Can Be Challenging – Some Things To Think About
Need for Speed
Container-Based WAN Monitoring
Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.