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-profiles 10 inbound
It's a more aggressive version of a SIP profile modifying only INVITES suggestion found here:
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.