Implementing calling restrictions with line blocking partitions and calling search spaces
In this recipe we will be implementing class of service calling restrictions using partitions and calling search spaces, as well as exploring their design considerations.
Getting ready
For this recipe, preparation is key. We will need to determine the partitions, calling search spaces, and patterns to be blocked that will be appropriate to the environment. There is more information on this in the There's more... section of this recipe.
How to do it...
To implement calling restrictions, perform the following:
- First, create the partitions with the necessary descriptions (Call Routing | Class of Control | Partition):
- Next, create the calling search spaces (Call Routing | Class of Control | Calling Search Space):
- Finally, add the translation pattern for the blocking patterns (Call Routing | Translation Pattern):
It is important to note here that we have used the Partition PT-US-Block-National with a Route Option set to Block this pattern.
Repeat this process for all the necessary blocking translation patterns.
How it works...
When a calling search space used for calling restrictions is applied to the directory number of a device, those settings override the calling search space patterns specified on the device, denying calls or access to certain numbers.
There's more...
While each environment is unique, there are some design considerations that apply to most. Calling restrictions is one of them.
In general, external calls fall in to one of these three classes:
- National/long distance
- International
- Premium
While the patterns for each category may vary according to region and requirements, these set up the foundation for our calling search spaces. Sometimes we find ourselves in need of an unrestricted calling search space. While you may choose to leave this to <none> on the directory numbers, I prefer to use an empty calling search space for clarity.
An example partition and calling search space arrangement for a US-based solution would be:
- CSS-US-Line-National
- PT-US-Block-National
- PT-US-Block-International
- PT-US-Block-Premium
- CSS-US-Line-International
- PT-US-Block-International
- PT-US-Block-Premium
- CSS-US-Line-Premium
- PT-US-Block-Premium
- CSS-US-Line-Unrestricted
- No partitions selected
This setup is not overly complex and can be easily used to expand calling restrictions to suit most environments.
There are two ways in which we can implement translation patterns for call restrictions, neither of which are mutually exclusive.
With careful consideration it is possible to bypass calling restrictions, though this is most typical for environments using E.164 call routing. In these environments it is typical for engineers accustomed to the traditional way of blocking to block digits as the user dials them. For example, if a user dials a premium number such as a 900 number, they typically do so with a 9 or 91 first, followed by the number, before hearing a message informing the user that the call was denied.
When using E.164 for call routing, this is not enough. In this type of environment there is usually a pattern for national calls, for example, 9.1[2-9]XXXXXXXXX. It is common to strip PreDot and prefix the plus sign for final routing. While this is the most common form of dialing, it is not the only way to dial.
On second generation and later phones, which Cisco calls Type-B phones, it is possible to dial a properly formatted E.164 number directly from the keypad, such as +19005551234, and have it routed. Because of this capability, it is important to add blocking patterns for the E.164 compatible number.
In environments that do not use E.164 call routing, calling restrictions are enforced primarily with route patterns set to Block this pattern, similar in setup to the translation pattern in this recipe's How to do it… section. Translation patterns may also be used for enforcing call restrictions.
In this type of environment, translation patterns are typically used to enforce call restrictions, though as with the traditional method, we may also use route patterns.
As mentioned in the Design considerations for preventing call restriction bypass section, it is possible to bypass traditional calling restrictions on Type-B phones by dialing the E.164 number directly. This is possible because of the added layer of routing associated with E.164 call routing.
To mitigate this and enforce call restrictions for these types of devices, we need to match the final number, which is in E.164 format. For example, if we want to block calls to 900 numbers we would implement the translation pattern \+1900XXXXXXX with the Route Option set to Block this pattern and a Partition of PT-US-Block-Premium.
In the previous example we have three partitions and four calling search spaces that enforce call restrictions at various levels: national, international, and premium. We include an empty calling search space to allow for unrestricted calls, called CSS-US-Line-Unrestricted for the sake of clarity, though in such cases a calling search space of <none> will suffice.
Represented by PT-US-Block-National, this class is used to prevent long distance calls or any calls on a national level that need to be blocked, such as fraud numbers. It is typically represented by the following patterns:
- For seven digit dial plans
- 91.[2-9]XXXXXXXXX
- \+1[2-9]XXXXXXXXX
In some cases it may be a requirement to proactively prevent users from dialing commonly known fraud numbers. Typically these are standard looking numbers that when called charge per minute connected. While this list is by no means complete, it is a good starting point for common fraud numbers in the US.
- 124[26][2-9]XXXXXX
- 126[48][2-9]XXXXXX
- 1284[2-9]XXXXXX
- 134[05][2-9]XXXXXX
- 1441[2-9]XXXXXX
- 1473[2-9]XXXXXX
- 1649[2-9]XXXXXX
- 1664[2-9]XXXXXX
- 1758[2-9]XXXXXX
- 1767[2-9]XXXXXX
- 178[47][2-9]XXXXXX
- 1809[2-9]XXXXXX
- 186[89][2-9]XXXXXX
- 1876[2-9]XXXXXX
- 1976[2-9]XXXXXX