There are several good write ups on how to block incoming calls on CUCM according to the CLID of the caller. The feature basically revolves around the ability to "
Route next hop by CNGID". To save reading another version, here's a link to one of the oldest and my favorite:
https://supportforums.cisco.com/t5/collaboration-voice-and-video/blocking-calls-based-on-calling-party-id/ta-p/3113978
Here's an image that summarizes it all:
A big caveat though that I recently ran into is how calls presented to CUCM over a SIP trunk are presented. In my case, if a caller was hiding their caller ID the
From: field in the SIP header contained the word "
anonymous" rather than being blank or including zeros or the like. The issue here is once you ask CUCM to route via the calling ID and if your calling ID is a word rather than some digits, you will find CUCM can't natively handle a request to route the call to a word. The call is rejected with a 404 error.
The link above includes references to a LUA script that might be applied to the SIP trunk in question. It also later references a change to the same LUA script.
I'm frankly not terribly comfortable depending on these scripts since I never craft them myself so I am effectively either relearning what they do on the fly or just blindly putting my faith into them.
The alternative I just used was this config on the CUBE routers in question:
voice class sip-profiles 10
request ANY sip-header From modify "<sip:anonymous@" "<sip:0000000000@"
voice service voip
sip
sip-profiles inbound
sip-profiles 10 inbound
It's a more aggressive version of a SIP profile modifying only
INVITES suggestion found here:
http://technologyordie.com/calling-party-routing-of-anonymous-calls-sip-header-fix-up
The idea is the same regardless. Replace the useless caller id (ie: the word "anonymous") with something else that CUCM understands (ie: 0000000000).
If you have been blocking calls like this and finding you and yours moving to SIP trunks, be forewarned and address it now.