- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
11-03-2011 11:09 PM - edited 03-12-2019 09:41 AM
Introduction
This document covers the Technotes for Blocking calls in Cisco Unified Communications Manager (CUCM) 8.x and later based on Automatic Number Identification(ANI) when CUCM is using MGCP Gateway.
- ANI (Automatic number identification) is a feature of telephony intelligent network services which permits subscribers to display or capture the telephone numbers of calling parties.
- DNIS (Dialed Number Identification Service) is a telephone service that identifies for the receiver of a call the number that the caller dialed. It's a common feature of 800 and 900 lines. If you have multiple 800 or 900 numbers to the same destination, DNIS tells which number was called.
Problem Description
When CUCMs are using MGCP gateways instead of H.323 gateways blocking calls based on ANI or Calling Number becomes difficult or not possible in older Cisco Unified Communications Manager (CUCM) versions which is below 8.x
From CUCM 8.x and later versions this task can be accomplished by using “Route Next Hop By Calling Party”
Note:
- If an MGCP gateway is used, from CUCM 8.x and later versions incoming calls can be blocked based on ANI or Calling Number. In the Older version of CUCM which is below 8.x, the only way to block unwanted calls is based on the DNIS information.
Solution
Block calls based on ANI in CUCM 8.x when CUCM is using MGCP gateway
MGCP GW -> inbound calling CSS called “Screen_all-incoming_calls_ANI_CSS” -> match to Translation pattern ! which has
“Route Next Hop By Calling Party” checked which changes the behavior to route the calls based on Calling number not the called number to next Calling search space called -> “block_certain_ANI-calls_CSS” -> which matches following transalation patterns shown as an example,
The CSS “block_certain_ANI-calls_CSS” should see following translations:
1) ! translation pattern with a CSS contains “All Phones partition” – This allows calls to route normally into the cluster.
2) 8001201 Blocking Pattern – Block calls coming from caller ID 8001201
3) 8601202 Blocking Pattern – Block calls coming from caller ID 8601202
Additional Information
Block calls based on ANI and DNIS when CUCM is using H.323 gateway
If an H.323 gateway is used, incoming calls can be blocked based on either Automatic Number Identifier (ANI) or Dialed Number Identification Service (DNIS) information, or both, through translation rules on the gateway (GW) configuration.
For an example of how to block calls based on specific calling numbers (ANI), refer to the Call Blocking Specific Calling Numbers
For an example of how to block calls based on specific called numbers (DNIS), refer to the Call Blocking Specific Called Numbers
Block calls based on DNIS when CUCM is using MGCP gateway
If MGCP gateway is used with the Older version of CUCM which is below 8.x the only way to block unwanted calls is based on the DNIS information. This is accomplished through translation patterns in the Cisco CallManager configuration.
An Translation pattern in CUCM must be created to match the inbound DNIS information (called party number). Then, the gateway in Cisco CallManager must be configured to have a Content Services Switch (CSS) with access to this Translation pattern first, based on the Translation pattern partition. Give the Translation pattern a CSS that has access to NOTHING. This sends the call nowhere, and the calling party receives a reorder tone.
Note: This method of blocking calls can only be accomplished based on the DNIS information (called party number) and not on the ANI (calling party number) information.
To block calls in the same manner at the Cisco CallManager level, use translation patterns. To do this, the DNIS or called number can be specified in a route pattern, then applied to the gateway. In this case, the "****" that is used to block the call is the Route or Block this pattern option.
Note: This can only block unwanted calls based on DNIS information and not on the ANI information.
Related Information
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Informative doc ..Thanks
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Very interesting, I did not know that this is now possible in 8.x
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Great doc, I remembered reading this before and it came in handy today to resolve a specific customer scenario!

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Shouldn’t the "Content Services Switch" be "Calling Search Space" near the bottom?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
This writeup was a little too high level for me.
I found one at DOC-18367 that is more my speed.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
This works well, but if you have multiple gateways, you'll want to spend some extra time planning the final-hop CSS. This solution won't scale well by cloning for each gateway, so you'll probably want to standardize the flow to be more of a global/regional solution.
For use, that means that our final-hop Translation Patterns are tied to a Partition that is included in the CSS for each MGCP Gateway. This works, but you'll want to design that part so that you don't have Translation Patterns that unintentionally overlap at each location, unless they translate to the same destination internally.
Very good write-up.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thank you Paul for sharing your thoughts and ideas. Glad to hear it works well.
Regards
Lavanya
Technical Community Manager - Voice
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Does this configuration also support ANI in the E164 format? Supposing that it is being modified on the gateway.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I implemented this on my CUCM 9.1.2 and it works to block specific numbers, but it does not allow "anonymous" or "unknown" callers to pass, which unfortunately is a deal breaker for us since many government entities call with this condition.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
In 9.1.x you can block anonymous calls at the Line level (checkbox). It's not as scalable, but it's there.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
While that's actually interesting for users who complain about anonymous callers, my goal is actually to NOT block anonymous calls in general, which the design in this article does, probably because the ! translation pattern does not pass alphanumeric characters.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hello
Refer to DOC-18367; it explains how to allow calls without caller id:
7) Some calls may arrive without caller id or a restricted caller ID. If you wish to allow calls without caller ID, there will also need to be a <none> or blank Translation Pattern. If the administrator does not define a <none> Translation Pattern, then all calls without caller id will be rejected.
***NOTE***
In this example, the Calling Search Space is selected as "Internal Phones"....select your Calling Search Space specific to the Calling Search Space your DN exists in.
E.G.: In step 7 above, the called number is "617589.XXXX", and it exists in the "Boston_MA_CSS". In order for any called DN to the "617589.XXXX" number to be reached from an "unknown", "blank", or "<none>" caller, the "blank", or "<none>" translation pattern MUST be have the CSS (Boston_MA_CSS) that the called number resides in....or else, ALL callers who DO NOT send Caller ID to the CSS where filtering is occurring will receive an "unallocated" carrier SIT tone followed by the carrier message:
"the number you have called is not in service".
Hope this explains it.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi All,
if you have SIP Trunk and you want to allow anonymous calls, you must apply this configuration in your cube:
voice service voip
sip
sip-profiles inbound
sip-profiles 10 inbound
exit
voice class sip-profiles 10
request ANY sip-header From modify "<sip:anonymous@" "<sip:+00000000000@"
Now all calls should pass-through to Call Manager, you must start see that SIP messages changed from anonymous to +00000000000 (you can change this number to anything else)
Regards,
Ahmad Kefaya
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@kdotten36 I know it’s years ago since you asked your question, but as it seems that you might not have gotten an adequate answer on it I’m linking to this post that explains the whole process of blocking calls in CM based on ANI in a very detailed manner.