Part 2 of the new “Route next hop by calling party” is probably the best use of this feature and probably more geared toward the purpose. This blog is a short snippet of an inbound dial-plan to block or redirect calls based on the calling party. Before the feature was released in CUCM 10.x calling party blocks had to be dealt with through dial-peers and translation rules on the gateway. In that method it could only be supported on H.323 or SIP gateways and required the admin to know a bit more about gateways to administer the list. In 12.x IOS code you were also limited to 15 patterns in the translation pattern before you had to start getting really creative.
Again we need to define a couple of new calling search spaces and partition. The goal of the first hop is to catch any call and forward it by calling party to our CSS that will then sort by the calling number. Here we can block or reroute the call to a different destination as needed. In some areas like government and healthcare you can’t actually block users from calling, but you can send them to a voicemail or an operator so the boss doesn’t get too annoyed.
In this example we are globalizing all our patterns on the gateway so we have a consistent number format to match against when it hits CUCM. Our first calling search space – PSTN-IN_RouteByCLID_CSS – has a single partition – PSTN-IN_RouteByCLID_PT. In that partition we have a single translation profile that catches all (!), sets the calling search space to match our special partition that filters by ANI – BLOCK_PSTN-CLID_CSS/PT, and enables the “Route next hop by calling party” flag.
In the BLOCK_PSTN-CLID_PT we can create rules that match our calling party as needed and either block or redirect the caller through called party transformations. If we need to get super fancy we could create a second CSS for “captured” calls and sort again based on the called party. This helps with issues like – I want Bob to be able to call Jane, but not Jim.
The only required translation profile in this partition is the catch all to route any unmatched call on as normal.
This is indeed a pretty quick blog, and once you’ve mapped out the items needed its pretty straight forward. I configure all deployments with this style of inbound dial-plan so that callers can easily be dealt with down the road without a rewrite.