OCS 2007 Dialplan fundamentals

I have noticed that many people, in particular those who have a telephony background or were working with common IP PBX solutions, try to match their gained dialplan know how, that they acquired over the last couple of years with many, many PBX/IP PBX projects, on OCS 2007. While there are few similarities with other IP PBX systems, there is at least one fundamental difference in the overall dialplan design of OCS 2007:

Traditional PBX and IP PBX dialplans were created mainly from a node-by-node or site-by-site perspective. If you had a node on site A and another one on site B in e.g. a different area code, the design of the dialplan was primarily focused on this particular site with some cross-node/cross-site prefixes in order to allow inter-site phone calls.

Here is an example: We have a PBX on site A with the subscriber number +4969000 with a 4-digit extension range (+4969000-xxxx). On the other hand we have a PBX on site B with subscriber number +4940000 and also 4-digit extension range (+4940000-xxxx). The two PBX systems were connected either physically or virtually with a direct link provided by a TDM (Time Division Multiplexing) carrier so that inter-site calls did not need to use the PSTN.

If now a user on site A with x1212 wants to make a phone call to the user on site B with extension 3699, she/he has to dial a site-prefix (that she/he needs to know of course, imagine this for 100s of sites!) followed by the extension of the user e.g. 88-3699. On the other hand, the user on site B has to dial 87-1212 in order to reach the user on site A with extension 1212.

PBX/IP PBX systems could even be configured to use the cross-site prefixes on incoming PSTN calls. So that a user in e.g. Hamburg could avoid a long-distance call to Frankfurt by dialing the local Hamburg subscriber number (here 000) followed by the cross-site prefix and the extension of the user (here 000-87-1212).

By using cross-site prefixes the dialplan of each site’s PBX could be kept unique. At any situation, even though if the same extension e.g. 1212 was given to a user of site A and to a user of site B, the dialplan was unique. If an incoming call from the PSTN on site B wanted to reach extension 1212 it was clear that extension 1212 on site B was meant. If another user on site B just dialed 1212 it was clear that she/he wants to cal extension 1212 on site B and not extension 1212 on site A, because then she/he would have dialed the cross-site prefix.

OCS has datacenter-model oriented architecture! This means it has been designed to provide real-time services (incl. voice/telephony) even for large enterprise environments by setting up a pool of OCS servers located in one or few worldwide datacenters. These datacenters are connected through the company’s corporate IP network with one another and all users, independent from their physical location, can connect via IP to these servers in order to receive real-time services. Effectively this means from a telephony perspective that formerly separate telephony nodes will be concentrated in one physical and logical location and therefore the formerly well-known site-oriented perspective on dialplans cannot be kept anymore as the uniqueness of the formerly known extensions cannot be maintained anymore.

So, how do the “extensions” have to be modified in order to become unique within the OCS “worldwide telephony system”?

The PSTN (Public Switched Telephone Network) gives an example of a telephony system where each endpoint has been given a unique numeric address, also called phone number. With this numeric address every endpoint can reach every endpoint and two endpoints do never have the same numeric address. The typical format that we are also all used to from our mobile phones is the E.164 format, usually written with a ‘+’ sign up front. Typical formats are

+<CountryCode><SubscriberNumber> or
+<CountryCode><AreaCode><SubscriberNumber>.

OCS uses this format to assign a unique phone number within the worldwide OCS environment to a user. This is one fundamental difference to most other PBX/IP PBX systems.

In the OCS world a phone number will be assigned to a user and not to a device. In the PBX/IP PBX world usually you would say: “This phone over there has extension 156”. So everyone initiating a call using this particular phone will obtain the identity that extension 156 represents. If this is usually Bob’s extension and Bill is initiating a call from it, callee John will have to assume that Bob is calling him on an incoming call. So Bill has to explain to John at the beginning of the call that he is not Bob. This is fairly easy even for John to notice as Bob and Bill will have a different voice, but in a Unified Communications environment where communication involves all media (e-mail, Instant Messaging (IM), video call, voice call, application sharing, SMS…) an outgoing call from Bill can be answered by John with an IM. Now, John has to be sure that he is communicating with Bob, because otherwise he might reveal information as part of the IM conversation that was not intended for Bill.

In order to avoid such situations in a Unified Communications (UC) environment, two things have to be assured by the system:

1. phone numbers need to be assigned to users in a worldwide unique fashion

2. Users need to identify themselves with the system before starting to communicate (e.g. Logon to Windows/Office Communicator using Windows credentials out of Active Directory)

In order to proceed with the example above, unique phone numbers for the sample users in Frankfurt and Hamburg would look like this:

The phone numbers will be assigned to users in the Active Directory user configuration as part of the communications tab. The “Line URI” field is the place where the user will receive her/his phone number. It’s also called msRTCSIPLine attribute. The format has to be in the following way:

tel : +<E.164> e.g. tel :+49690001212 or tel :+49400001212

What’s now becoming obvious, is that this format is not a really user friendly. Simone in Frankfurt who had extension 1212 with the previous PBX/IP PBX system might argue that it is not very comfortable for her to dial +49690003699 just to reach her coworker Christine who is sharing an office with her and had extension 3699 before the OCS roll-out. Agreed! In order to preserve the users dialing behavior and to allow an easier adoption of the OCS system as an enterprise voice solution, logical “dialing zones” can be built in OCS around a number of users of the same site that have the same dialing behavior. These zones are called “Location Profiles”. A Location Profile is a set of regular expressions that modify a called party number to the +<E.164> format that is uniquely used within the OCS environment to assign phone numbers to users. These regular expressions allow Simone to enter 3699 and based on her Location Profile the number will be expanded by Office Communicator to +49690003699 before sending to the system. This is transparent for Simone and she doesn’t need to know this. (After a while Simone will become used to the fact, that it is much easier to call Christine by clicking on a contact in OC or on a button in Outlook, but for the beginning of the adoption she should be able to maintain her previous dialing behavior.) If Simone wants to make an outbound call to the PSTN, she also can keep her behavior to dial “0040…” for a call from Frankfurt to Hamburg (First “0” is an external line prefix and second “0” needs to be dialed within Germany to reach other area codes) as the regular expressions of the Location Profile will convert this called party number to +4940… by replacing the first two leading “0” with “+49”.

For the example above we will have two Location Profiles, one for all Frankfurt users named “FRA” and one for all Hamburg users “HAM”.

How to create Location Profiles on OCS will be explained in a separate blog article. Location Profiles are assigned to Office Communicator users by Windows Group policy. An article about this topic can be found here. On Office Communicator Phone Edition 2007 users are able to change their Location profiles by themselves.

Up to this point we have seen that local Location Profiles on OCS solve the problem of having duplicate extensions on one worldwide, enterprise-wide voice system as well as the need for cross-site prefixes as known in the site-oriented PBX world.

We have to keep in mind though that endpoints on OCS at the end are not registered with a tel URI (+4940000xxxx) but with a SIP URI (Session Initiation Protocol Uniform Resource Identifier) of a user (sip:example@company.com). So if Simone in Frankfurt dials 3699 to reach Christine, the regular expressions of the Location Profile will modify this called party number to +49690003699 and after that the User Services application of OCS will try to match this phone number to its entries of the msRTCSIPLine attribute field in the User Database. If the entry matches (this means that the called party has been enabled for Enterprise Voice on OCS), a SIP URI of the called party will be retrieved and a SIP session (SIP session with media voice = phone call) can be established between the two SIP users. If no SIP URI can be found within the OCS User Database that matches the modified called party number, this means that there is no user on the OCS system who has this tel URI (phone number) assigned. This means further that the called party has to be found in the outside OCS world.

To summarize at this point: Here are the three options to establish a voice call using OCS:

1. To enter the SIP URI (by clicking on contact in Office Communicator, by typing the SIP URI into Office Communicator …)

2. To enter the tel URI in the +<E.164> format (like you are used with your cell phone when e.g. dialing international numbers)

3. To enter a non-E.164 phone number

What happens on OCS?

1. OCS will send a SIP INVITE message to the entered SIP URI

2. OCS Translations Application will try to match the tel URI in +<E.164> format to a SIP URI of his User Database. If successful, SIP URI will be retrieved and SIP INVITE will be sent to the found SIP URI

3. Office Communicator will apply Regular Expressions of the Location Profile that the user has been assigned to. As a result of this Number Normalization process, a +<E.164> format number will be generated and sent to OCS. Further on as above in step 2.

If OCS has determined that a call is not in the OCS world (Reverse Number Lookup fails as no SIP URI can be found that matches a dialed +<E.164> number by a user), the call needs to be handed over to the outside-OCS telephony environment. For voice calls the boundary to the outside world (PBX with Gateway, Gateway connected to PSTN, SIP carrier…) is built by an OCS Mediation Server. While OCS Audio/Video Edge Server builds the boundary to the Internet for calls to Remote users or to other federated enterprises that use OCS as well, is the OCS Mediation Server break in/out point for connections to non-OCS users, currently mostly used for voice calls.

In the example above two OCS Mediation Servers with Media Gateways sitting between the PSTN and the OCS Mediation Servers have been added. One sitting in Frankfurt/Germany and the other one sitting in Hamburg/Germany. After the decision has been made by the OCS system that the endpoint called party number must belong to an endpoint outside of the OCS world, two things have to happen as part of the OCS Outbound Routing application:

1. It has to be checked by the system whether the user is allowed to dial this number to the OCS-external world.

2. OCS has to determine the most suitable break-out point (OCS Mediation Server) to hand over this call to the outside OCS world.

In common PBX/IP PBX system class of service rights have usually been assigned to extensions. Extension 1212 was allowed to make internal, local and national calls, while extension 3699 was allowed to make internal, local, national and international calls but no calls to premium numbers (e.g. 900). In OCS users will be tagged with attributes (representing “dialing rights”) and not extensions. There can be an attribute called “local” but there can also be an attribute “local_and_national”. These attributes are called “Phone Usages” in the OCS world. It is also possible to name the Phone Usages “A” and “B” as while defining Phone Usages they have no immediate relevance on the numbers that a user is allowed to dial. So don’t get confused.

One or multiple Phone Usages will be grouped in a so called “Voice Policy”. In the screenshot above of the Active Directory user configuration it is shown how a user will be assigned to a Voice Policy. There could for example be a Voice Policy named “InternationalGER-Premium” that includes the Phone Usages “Internal”, “Local”, “National-Premium”, “International”.

Phone Usages determine which “Route” a user is allowed to use for an outbound phone call. An OCS Route consists of a regular expression rule, one or multiple Phone Usages and an OCS Mediation Server FQDN (Fully Qualified Domain Name). The user is allowed to make an outbound call using a particular Route when the following two parameters match:

1. The dialed and normalized +<E.164> number matches the regular expression rule for this Route

2. The Phone Usage(s) for a particular route matches the user’s Phone Usage attribute (assigned to the user via Voice Policy) for this particular Route.

Here is an example: The Frankfurt user Simone has the Phone Usage attributes:

User Simone:

Location Profile:               FRA
VoIP Policy                          “NationalNoPremiumGER”
Phone Usages:                  “Internal” and “NationalGER-Premium”

OCS Routes:

She dials 0230001 in order to call for a taxi (“0” is the outbound dialing prefix). With the regular expressions of the Location Profile “FRA” the number will be normalized to +4969230001, Reverse Number Lookup fails as no SIP URI can be matched to this number and a Route needs to be determined to break-out this call to the PSTN. The user Simone has been tagged with two Phone Usages via VoIP Policy “NationalNoPremiumGER”. “InternalFRA” and “NationalGER-Premium”. The order of these Phone Usages in the VoIP Policy is important! OCS Outbound Routing will first apply regular expressions on the normalized called party number of these routes that have been tagged with the Phone Usage attribute “InternalFRA”. The regular expression for an “InternalFRA” route will look like ^\+4969000 as this Route should only be used for calls that are within the Frankfurt company site.

Since regular expression does not match the called party number, there cannot be a Route found for the Phone Usage attribute “InternalFRA”, OCS Outbound Routing will try to find a Route for this number to match for the second Phone Usage attribute “NationalGER-Premium”. A Route that matches this Phone Usage attribute would e.g. have the regular expressions ^(?!(\+49(?!(190|900)))) which basically means that the regular expression matches for all phone numbers starting with +49 but not +49190 or +49900, which are premium numbers. So if Simone would have dialed a premium number the regular expression would not have matched and Simone would not have been able to dial this number.

Simone has dialed +4969230001. Therefore the regular expression for this route will match. Since Phone usage attribute and regular expression match, a SIP INVITE will be sent to the particular OCS Mediation Server FQDN for this particular route and Simone is able to make this phone call.

An OCS Mediation Server is either connected via IP to a SIP IP PBX or via IP to a SIP/TDM Gateway that is connected either to one or multiple PRI (Primary Rate Interface , E1=30 channels, T1=23 channels) tie line of a TDM PBX or to the PSTN. In either way the next hop after the OCS Mediation Server has to modify the normalized +<E.164> number back to a format that is expected of following hops. In case that OCS Mediation Server is e.g. connected to a SIP/PSTN Gateway, the Gateway has to convert Simone’s call from +4969230001 to 230001 as expected for a local call by the PSTN.

I have prepared an Enterprise Voice Route Helper file (this is the tool you should always use to configure OCS 2007 dialplans, which you can get here) for the example above. You can download the example here (I have excluded the complexity around Emergency Numbers in this example but I have added a translation rule for the cross-site prefix that allows the user to dial the previously used cross-site prefixes):