Outbound Dial Control and Authorization (or how OCS implements its own Checkpoint Charlie)

Dialing authorization is definitely one of the main concerns of any PBX Administrator, maybe even more now that the economy is forcing most companies to reduce costs.

Since Office Communications Server (OCS) 2007 R2 has all the necessary telephony capabilities to replace the PBX, it should offer the same dialing control as those legacy PBX’s… And it does!

Before diving into further detail, let’s first introduce some terminology and concepts associated with OCS:

Object	Description
Location profile	A location profile defines all phone numbers that can be dialed from a named location. A location contains one or, typically, more normalization rules.
Normalization rule	A normalization rule is a .NET regular expression that defines a phone number pattern. A set of normalization rules associated with a particular location constitutes a location profile.
Phone usage record	A phone usage record specifies a class of call (such as internal, local, or long distance) that can be made by various users, or groups of users, in an organization.
Voice policy	A voice policy associates one or more phone-usage records with one user or a group of users.
Route	A voice route associates target phone numbers with particular IP-PSTN gateways and phone usage records.

In order to define different levels of dialing privileges, we must create different Voice Policies (that must be assigned to the different users), which in turn control the access to the outbound Routes. And in the end, it’s all about the Routes, Routes act as the Checkpoint Charlie of outbound calls: if a user is configured with a Voice Policy, that contains a certain Phone Usage, that is associated with a Route for the dialed number, then the call is successfully placed.

Confused? I’ll give you an example shortly, but before, take a look at this diagram from Microsoft TechNet site User Authorization and Outbound Call Routing Requirements:

Dd425155.37df1bae-c892-4f65-8fc1-837502949388(en-us,office.13).gif

A practical example

From my field experience, I noticed there is more or less a pattern from all my customers regarding the types of outbound call privileges, which is:

Internal Extensions – These kind of users can only place calls to internal extensions.
National Land Lines – Users with this policy defined may dial internal extensions and national land lines.
National Mobile Numbers – These will be the users allowed to dial the previous type of numbers plus national mobile phones.
International Numbers – For those users who need to place international calls, as well as national, of course, this will be the appropriate level of authorization. This policy doesn’t allow dialing value added numbers.
All Calls – The lucky ones assigned with this level of authorization may dial any number they want.

This simple practical example will cover a single location with a single point of exit to the PSTN. It will be relatively easy to derivate from this sample example and build more complex scenarios.

If you noticed the above diagram, the first step is to define the location profile(s) and to configure normalization rules, which I won’t cover in this post (if you want to know the details, please read Location Profiles and Normalization Rules).

So I’ll start instead from the Phone Usage Records definition. The picture below depicts the 5 phone usage records created in this practical example, one for each of the outbound calling privileges described previously.

The next step is to create the corresponding voice policies. Once again there is a voice policy for each of the phone usage created previously, as depicted in the following picture:

Notice that Use per user policy is selected, as opposed to selecting a default global policy, since we want to differentiate the privileges each user has.

Since the users with more dial out privileges must also be able to place less privileged calls (users allowed to dial mobile numbers can also dial internal extensions, for example), the more “advanced” policies must include the less privileged phone usages, as the following pictures illustrate.

The final step is to create the voice routes, and once again, there will be one route for each phone usage, plus one for the emergency number. The following table provides a brief explanation of the different routes configured:

Route	Target Regular Expression	Comment
Internal Extensions	^\+?(\d{4})$	Internal extensions with 4 digits
National Land Lines	^\+351(2\|3\|8)(\d{8})$	The expression matches the country code for Portugal (+351) followed by 9 digit numbers starting with 2, 3 or 8
National Mobile Numbers	^\+3519(\d{8})$	The expression matches the country code for Portugal (+351) followed by 9 digit numbers starting with 9
International Calls	^\+?(?!(351(760\|761\|762)))(\d*)$	The pattern matches any kind of number, except the valued added numbers for Portugal: anything that begins with either 760, 761 or 762, plus the country code.
Universal Calls	^\+?(\d*)$	The pattern used is the universal route, so any number can be used
Emergency Number	^\+?112	The national emergency number for Portugal is 112

Here’s an image of the Routes tab from the OCS Voice Properties dialog box:

Each route has only the corresponding phone usage associated, except the emergency route, which has all the configured phone usages, as illustrated below:

Testing and validation

Now that everything is in place, we need to test if the different configured user profiles work as expected. There is a neat tool, part of the Microsoft Office Communications Server 2007 Resource Kit Tools that really suits this task: Enterprise Voice Route Helper. For detailed instructions on how to use the tool, there is a comprehensive user’s guide available to download.

All the different combinations between voice policies and the different possible outbound numbers should be tested, but for demonstration purposes I’ll use only 2 test cases:

A user with the Default Policy dials the emergency number
A user with international call privileges dials a value added number

For the first scenario the call is permitted and routed out, as you can see in the following picture:

As for the second test case, the call is blocked, with the message “Unable to route”.