This is a slightly modified repost of a blog article that I previouly published here.
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 dial plan 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 dial plan design of OCS 2007:
Traditional PBX and IP PBX dial plans were initially created as standalone numbering plans on each PBX node. For building larger PBX networks, PBX nodes were linked together either virtually or physically by using digital-, analogue- or IP- trunks, and proprietary- or QSIG- signaling between the PBX nodes. Internode PBX calls can use existing trunk resources (toll free), instead of using the PSTN.
A basic requirement for the networking of different PBX nodes is an unique subscriber number in the whole PBX network.
An unified dial plan with “unique subscriber numbers” can be implemented using one of the following numbering concepts:
· “homogenous numbering plan”:
o Renumbering all subscriber numbers and so having unique subscriber numbers in the network.
· “hidden numbering plan” or “Heterogonous numbering plan”:
o Adding a “node prefixes” to all subscriber number on a PBX node.
o Hiding numbers by moving the overlapping subscriber numbers to unused numbering range in the numbering plan (providing an unique number)
The networking of PBXs allows an easier dialing of network subscriber numbers on different PBX nodes, by dialing abbreviated numbers, or internal numbers (extensions with 3, 4….,9 digits instead of the whole subscriber number) which will be automatically converted through the PBX, by adding a prefix to dialed number.
Here is an example: We have a PBX on site A with the subscriber number +4969100 with a 4-digit numbering range (+4969100-xxxx). On the other hand we have a PBX on site B with subscriber number +4940200 and also 4-digit numbering range (+4940200-xxxx).
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 200) followed by the cross-site prefix and the extension of the user (here 200-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 call 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:
| User A1 | +49691001212 | User B1 | +49402001212 |
| User A2 | +49691003699 | User B2 | +49402003699 |
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:+49691001212 or tel:+49402001212
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 +49691003699 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 +49691003699 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 (tel:+4940200xxxx) 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 +49691003699 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 the 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, it is the OCS Mediation Server which provides the 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:
| Description | Regular expression | Phone Usages | Mediation Server FQDN |
| Internal FRA calls | ^\+4969100 | Internal | GwFRA.company.com |
| Internal HAM calls | ^\+4940200 | Internal | GwHAM.company.com |
| National GER calls No Premium | ^(?!(\+49(?!(190|900)))) | NationalGER-Premium | GwFRA.company.com |
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 ^\+4969100 as this Route should only be used for calls that are within the Frankfurt company site.
| Description | Regular expression | Phone Usages | Mediation Server FQDN |
| Internal FRA calls | ^\+4969100 | Internal | GwFRA.company.com |
| Internal HAM calls | ^\+4940200 | Internal | GwHAM.company.com |
| National GER calls No Premium | ^(?!(\+49(?!(190|900)))) | NationalGER-Premium | GwFRA.company.com |
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.
| Description | Regular expression | Phone Usages | Mediation Server FQDN |
| Internal FRA calls | ^\+4969100 | Internal | GwFRA.company.com |
| Internal HAM calls | ^\+4940200 | Internal | GwHAM.company.com |
| National GER calls No Premium | ^(?!(\+49(?!(190|900)))) | NationalGER-Premium | GwFRA.company.com |
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 off 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):