Jochen Kunert : Phone Usage

OCS 2007 German dialplan example

jkunert — Wed, 27 Aug 2008 18:05:00 GMT

This blog article presents and explains an OCS 2007 Dialplan that has been created for the location Germany (Country code +49) Cologne (Area code 221). In this example the company has a local subscriber number 000 and a 4 digit extension range.

We assume that there is only one OCS 2007 Mediation Server with the FQDN (Fully Qualified Domain Name) ms.com and that on outbound calls the next hop element after Mediation Server (e.g. a SIP Media Gateway or a SIP IP PBX) takes care on normalizing called party numbers from +<E.164> format back to a proper format that again the next hop after that (e.g. PSTN) would expect. The only exception is emergency numbers that are sent as is prefixed with a + sign, so that the next hop after OCS 2007 Mediation Server just has to remove the + sign.

It makes sense to start with the creation of a Location Profile that allows users to maintain their current dialing behavior as they are used to from their previous voice solution. A good starting point is to collect from every site the following most common dialing behaviors:

· Common emergency call dialing pattern

· Common internal dialing pattern (e.g. 4 digit dialing)

· Common local dialing (what’s the external line prefix?)

· Common national dialing pattern

· Common international dialing pattern

These common dialing patterns should at least be incorporated into a Location Profile. As a result of the regular expressions of a Location Profile is (except for a few exceptions as mentioned above) an +<E.164> normalized number string.

External line prefix: Most PBX systems use an external line prefix to distinguish internal calls from external PSTN calls (Example: How else should be distinguished between the internal extension 112 and the external emergency phone number?). This pattern worked for the last 30 years in the PBX world, it’s there for a good reason and users are used to it. So, do not change this behavior during the implementation of an OCS 2007 dialplan. There are high chances that numbering conflicts occur in the long run.

Coming back to the example. People of the fictitious company in Cologne/Germany are used to dial:

· 0110, 0112 Police, Fire fighters

· 0116116 Emergency number for data accidents

· 1234 Intracompany call

· 01234.. Local call, same area code

· 001234… National call

· 0001234… International call

This dialing pattern leads into the following location profile:

Dialed Number example	Pattern	Translation	Normalized Number Sent from MS to next hop	Next hop to PSTN
0110	^0(11[02])$	+$1	+110	110
0116116	^0(116116)$	+$1	+116116	116116
1234	^([1-9]\d{3})$	+49221000	+492210001234	-
012345	^0([1-9]\d{1}\d+)$	+49221$1	+4922112345	12345
0012345678	^00([1-9]\d{1}\d+)$	+49$1	+4912345678	012345678
00012345678	^000([1-9]\d{3}\d+)$	+12345678	+12345678	0012345678

Here are some remarks to the rules above:

Rule 1,2: Emergency numbers will not be prefixed with a country or area code. Just with a ‘+’ sign. The next hop needs to remove the + sign and send it out to the PSTN.

Rule 3: The next hop behind OCS 2007 Mediation Server needs to remove the prefix +49221000.

Rule 4: Local, same area code calls will be sent to the PSTN w/o leading 0. This way directory services like 11831, 11833 … work as well with the same rule.

Rule 5: To dial a national call within Germany, the area code needs to be prefixed with a 0 and sent to the PSTN such way. The replacement of +49 with 0 before sending out to the PSTN is task of the next hop.

Rule 6: International calls need to be prefixed with 00 before sent out to the PSTN. So the next hop after Mediation Server needs to replace ‘+’ with 00.

At this point, here are a couple of important notes:

Complexity around Office Communicator Phone Edition on-hook quick dialing experience has been excluded in this example on purpose.

Users will be assigned to Location Profiles in OCS 2007 based on Windows Group policies. In current Windows environments, users will be assigned to Group Policies not with respect to their physical location. So please be careful which Location Profile to add to which users.

Keep in mind as I have described in a previous blog about OCS 2007 dialplan fundamentals, that normalization rules can be bypassed by entering a +<E.164> number. So do not try to implement dialing authorizations in the normalization rules as they can be easily bypassed by the user when using +<E.164> format phone numbers.

After the creation of a Location Profile for our site in Cologne/Germany, Voice Policies (dialing authorizations) need to be created for the different type of users. In this example we’ll have 6 different classes of dialing authorizations (this is what the user is allowed to dial). I have picked self explaining names. The leading digit just shows a hierarchy of the different dialing authorization levels:

VoIP Policy	User assigned to this VoIP policy is allowed to dial…
1EmergencyGER+InternalCGN	Emergency Numbers Internal Numbers on CGN company site
2EmergencyGER+InternalCGN +NationalGER-MobileGER- PremiumGER	Emergency Numbers Internal Numbers on CGN company site National Numbers No National Mobile Numbers No National Premium Numbers
3EmergencyGER+InternalCGN +NationalGER+MobileGER-PremiumGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers No National Premium Numbers
4EmergencyGER+InternalCGN +NationalGER+MobileGER+PremiumGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers National Premium Numbers
5EmergencyGER+InternalCGN +NationalGER+MobileGER- PremiumGER+InternationalGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers No National Premium Numbers International Numbers
6EmergencyGER+InternalCGN +NationalGER+MobileGER +PremiumGER+InternationalGER	Emergency Numbers Internal Numbers on CGN company site National Numbers National Mobile Numbers National Premium Numbers International Numbers

With the notion of Phone Usages it is possible to select certain routes for a specific call to be used. The user is allowed to dial a certain number if Outbound Routing can match the phone number to a route pattern and the user is equipped with the particular phone usage that’s needed to use this route. The available Phone Usages are:

· EmergencyGER

· InternalCGN

· NationalGER-MobileGER-PremiumGER

· MobileGER

· PremiumGER

· InternationalGER

A user that has been assigned to VoIP policy 3EmergencyGER+InternalCGN+NationalGER+MobileGER-PremiumGER has been “tagged” with the following attributes (phone usages):

· EmergencyGER

· InternalCGN

· NationalGER- MobileGER-PremiumGER

· MobileGER

The order of the phone usages is highly important as well as that there are no overlapping routes (A route that allows something that a different route tried to forbid). Here are the routes for this example:

Description	Pattern	Phone Usage	Mediation Server
EmergencyGER	^((\+110)\|(\+112)\|(\+116116))	EmergencyGER	Ms.com
InternalCGN	^\+49221000	InternalCGN	Ms.com
NationalGER-MobileGER-PremiumGER	^\+49(?!(15\|16\|17\|900))	NationalGER-MobileGER-PremiumGER	Ms.com
MobileGER	^((\+4915)\|(\+4916)\|(\+4917))	MobileGER	Ms.com
PremiumGER	^\+49900	PremiumGER	Ms.com
InternationalGER	^(?!(\+49))	InternationalGER	Ms.com

If a user of the VoIP Policy 3EmergencyGER+InternalCGN+NationalGER+MobileGER-PremiumGER and the Phone Usage attributes “EmergencyGER”, “InternalCGN”, “NationalGER- MobileGER-PremiumGER” and “MobileGER” dials a German mobile phone number like +491710000000, the following things happen:

First Outbound Routing will check all routes for the first Phone Usage attribute “EmergencyGER”. There is only one route with this Phone Usage attribute. But the number +491710000000 does not match the pattern ^((\+110)|(\+112)|(\+116116)). Therefore the user is not allowed to dial this number based on the first Phone Usage attribute.

As a next step, Outbound Routing will try to match the dialed phone number to a route that’s tagged with the second Phone Usage attribute “InternalCGN”. Same result. Dialed number doesn’t match the pattern for the route InternalCGN and therefore the user is not allowed to dial this number based on the Phone Usage attribute “InternalCGN”.

Let’s check the next Phone Usage attribute “NationalGER- MobileGER-PremiumGER”. Here is important when you look at the pattern of this route, that German Mobile Numbers and German Premium Numbers have been excluded. ^\+49(?!(15|16|17|900)) (! means: Not). So a user who would just have this Phone Usage attribute would not be able to dial this number.

In order to dial this number, the user needs to have the Phone Usage attribute “MobileGER” as this is the only Phone Usage attribute that’s assigned to a route that contains German Mobile Phone numbers ^((\+4915)|(\+4916)|(\+4917)). Now the dialed number matches the route pattern and the Phone Usage attribute of the user matches as well and the user is allowed to dial this number.

OCS will pass this call on to OCS 2007 Mediation Server. OCS 2007 Mediation Server will pass this call on to the next hop that needs to modify the called party number back to 01710000000 before sending out to the PSTN.

An Enterprise Voice Route Helper file with this example can be downloaded here:

OCS2007 Telephony integration options overview

jkunert — Mon, 25 Aug 2008 17:30:00 GMT

This blog article shows integration options of OCS installations with existing telephony environments from a high-level perspective.

An OCS 2007 voice deployment in a corporate environment typically starts with a pilot installation. Within this pilot installation, a handful of users, users of an entire department or an entire user population of a small enterprise site will be equipped with Office Communicator (OC) or Office Communicator Phone Edition (OCPE). The company has to decide whether they think that the right approach for their users to become comfortable with OC/OCPE is to get OC/OCPE in addition to or as a replacement for their currently used phones. The decision to remove a couple of phone extensions and replacing them with OC/OCPE has nothing to do with the final decision to replace the current TDM PBX/IP PBX with OCS! Sometimes I notice that there is confusion.

The adoption of OC/OCPE by users as the user’s “corporate telephone” is significantly depending on the design of the integration with the existing telephone environment. If the goal of the OCS voice pilot is to get experiences with Microsoft’s Unified Communications approach and its impact on the daily business, the migration of the existing user phone number to OC/OCPE should be targeted and OC/OCPE should be the only voice solution on the user’s desktop. Why? As long as a user has e.g. a PBX phone and OC standing on their desk, she/he will always fall back to the phone in case the user gets unsure about a specific functionality. Therefore the user is not challenged to change its usual behavior, occasionally even rethink his current behavior or adopt new behavior. E.g. if the user’s previous PBX phone always rings on incoming calls, the user will tend to accept or reject the call on this device. She/He will not notice the value of responding an incoming call with an Instant Message (like “not now, 5 mins”) and will continue e.g. to reject the call on the PBX phone so that the caller will be transferred to voicemail, leaves a message, this message has to be listened to by the user …

What are the integration options now to provide a smooth migration scenario that’s transparent for the users? One or multiple OCS 2007 Mediation Servers build the boundary to the outside OCS telephone environment. All supported connections of OCS 2007 Mediation Server on the non-OCS side can be found on Microsoft’s Open Interoperability Page. Based on this list, the following integration options with existing corporate telephone systems can be identified:

1. Connection via SIP Media Gateway

a. “MS-Gateway-PBX” scenario
The SIP Media Gateway will be connected to trunks provided by a TDM PBX

b. “MS-Gateway-Gateway” scenario
The SIP Media Gateway will be connected to trunks provided by an IP Gateway

c. “MS-Gateway-PSTN” scenario
The SIP Media Gateway will be connected to trunks provided by a PSTN carrier

d. “MS-Gateway-IP PBX” scenario
The SIP Media Gateway will be used as a SIP-SIP Gateway to provide protocol translation between SIP on OCS Mediation Server side and SIP on another vendors IP PBX side

2. Connection directly via SIP

a. “MS-IP PBX” scenario
OCS Mediation Server will be directly connected via SIP to a SIP IP PBX

Connection via SIP Media Gateway

“MS-Gateway-PBX” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected to a PRI trunk to an existing TDM PBX. This TDM PBX is connected with one or multiple PRI (Primary Rate Interface, E1=30 channels or T1=23 channels) to the PSTN. DID extension number range is 5 digit.

A PRI trunk connection will be used to route calls between the OCS system and the TDM PBX. On an incoming call from the PSTN or from another PBX extension, the PBX will route the call to the user extension (here e.g. 38999) via the PRI trunk connection to the SIP Media Gateway which is connected to OCS Mediation Server. On an outbound call from an OC user (here e.g. 38999) to a remaining PBX user or a PSTN subscriber number, OCS will route the call via OCS Mediation Server and the PRI trunk to the TDM PBX. The TDM PBX afterwards has to route the call to the designated PBX extension or to the PSTN.

“MS-Gateway-Gateway” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected to a PRI connection that’s been provided by an existing IP PBX Gateway. This is a possible integration option for those companies that have an IP PBX that has currently not been certified for direct SIP connection with OCS Mediation Server.

On the existing IP PBX/IP PBX Gateway a route will be configured that routes calls for OCS extensions to the PRI trunk connection where the certified SIP Media Gateway is connected. Incoming calls from the PSTN or other IP PBX extensions will be routed by the IP PBX via IP PBX Gateway/SIP Media Gateway and OCS Mediation Server to the OC user.

“MS-Gateway-PSTN” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected directly to the PSTN. The company has e.g. an old TDM PBX that does not offer the capabilities to provide a PRI trunk for SIP Media Gateway connection or the company had no corporate phone system at all (e.g. they only had cell phones).

There are multiple integration options now. One option is to order a new PRI link from the PSTN with a new number range and to forward the PBX extensions via the PSTN to the new PRI link. In this scenario the OCS user gets a new phone number and another disadvantage of this solution is that the OCS user usually just gets incoming calls from his old phone number as the forwarding phone number will be signaled on an incoming call and not the correct calling party number.

Another option is to connect the old TDM PBX to a PRI connection provided by the SIP Media Gateway. The SIP Media Gateway routes calls coming from the PSTN based on the dialed extension number to either OCS Mediation Server or to the trunk connection and therefore to the TDM PBX. This is an elegant way if most users have already been migrated to OCS Mediation Server and only a few users/extensions like e.g. fax machines, modems, alarm systems remained on the TDM PBX.

The last option is for recommended in such situations where only a handful of extensions could not be migrated to OCS. There are SIP Media Gateways on the market that provide ISDN BRI (Basic Rate Interface) or analog connections for extensions directly on the Gateway.

“MS-Gateway-IP PBX” scenario

In this scenario OCS Mediation Server is connected to a SIP Media Gateway which is connected to an IP PBX via IP connection. This is a recommended scenario for such IP PBX systems that have not been certified yet for direct SIP connection with OCS Mediation Server and the back-to-back SIP Media Gateway approach (“MS-Gateway-Gateway” scenario) does not seem to be appropriate.

The SIP Media Gateway has no PRI trunks connected but acts as an IP-IP protocol conversion Gateway. Depending on the Gateway it is possible to connect e.g. an H.323 IP PBX with SIP OCS Mediation Server or a SIP OCS Mediation Server with another vendor’s SIP IP PBX that has not yet been certified.

Connection directly via SIP

“MS-IP PBX” scenario

In this scenario OCS Mediation Server is directly connected via IP to another vendor’s SIP-based IP PBX that has been certified for direct SIP connectivity with OCS Mediation Server.

On an incoming call from the PSTN or from another IP PBX extension, the existing IP PBX routes the call to OCS Mediation Server and finally to an OC user. On an outbound call from an OC user to the PSTN or to an IP PBX extension, OCS will route the call to OCS Mediation Server which will route the call to the existing IP PBX. The IP PBX has to route the call after that to either the designated IP PBX extension or to the PSTN.

Conclusion

All the presented integration options above are possible integration options for OCS users that have been enabled for Enterprise Voice (also see here). Some of the direct SIP connection options (currently there is only one) can be used also for Dual Forking or Dual Forking with Remote Call Control if this connection option has been specifically called out on Microsoft’s Open Interoperability Program website.

OCS 2007 Dialplan fundamentals

jkunert — Fri, 15 Aug 2008 18:00:00 GMT

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:

User A1	+49690001212	User B1	+49400001212
User A2	+49690003699	User B2	+49400003699

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 (tel:+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:

Description	Regular expression	Phone Usages	Mediation Server FQDN
Internal FRA calls	^\+4969000	Internal	GwFRA.company.com
Internal HAM calls	^\+4940000	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 ^\+4969000 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	^\+4969000	Internal	GwFRA.company.com
Internal HAM calls	^\+4940000	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	^\+4969000	Internal	GwFRA.company.com
Internal HAM calls	^\+4940000	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 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):