Cisco CUCM Blocking Calls by Calling Party Number (ID)

Background

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
 direct-inward-dial
 port 0/0/1:23
 forward-digits 10
!

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:

1. The PSTN carrier presents the call to the voice gateway.
2. The voice gateway processes the call and then relays call setup information to the CUCM.
3. The gateway object in CUCM is configured to use CL_PSTN-In_CSS, which is used for the initial digit analysis step.
4. 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
5. Assuming that a CPN is present, CUCM will continue digit analysis using CL_PSTN-Screen_CSS.
6. 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.

1. 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.
2. 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.
3. Assign the CL_PSTN-In_CSS to the voice gateway.
4. 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.
   
5. Add the “allow all” translation “!” to CL_PSTN-Screen_CSS, enable call routing, and DO NOT enable “Route Next Hop by Calling Party Number”.
   
6. Add any “black list” translation. Enable call blocking, select disconnect cause reason, and you are good to go.
   

Considerations

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.)

Conclusions

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