Jochen Kunert : normalization rules

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:

OCS 2007 dialplan using non-DID numbers

jkunert — Tue, 19 Aug 2008 16:15:00 GMT

In a previous blog article OCS 2007 dialplan fundamentals I have excluded the complexity around non-DID (Direct Inward Dialing) numbers for syntactic reasons. In this blog article I will describe how to handle non-DID numbers in an OCS 2007 dialplan.

A non-DID number is a phone number, that cannot be reached directly from the PSTN. Such a phone number can be dialed within a corporate PBX/IP PBX network by dialing an extension number, but this extension number is not publicly reachable from the PSTN. However, it is technically possible, if the extension has not been restricted, to dial a PSTN phone number from a non-DID extension. In General, the corporate main phone number will be signaled as calling party number to the external callee so that the external callee can initiate a call back to the user by using this main number. The call back will result in a call to the receptionist or an auto attendant that offers the possibility to the PSTN caller to enter e.g. by DTMF tones to postdial the user’s non-DID extension after the connection had already been established.

To proceed with the example introduced in the blog OCS 2007 dialplan fundamentals:

Within the Frankfurt site there is a number block on the PBX (extension range 50000-50999) that is a non-DID phone number range. The sample company had usually a 4-digit extension range from 1000 to 9999 but with the exception of the 5000-5100 range where this range has been expanded to 5 digits. This is from the German PSTN numbering plan possible as there is no fixed number length as for example in the USA, Denmark or France. If we take a look at the local dialplan for the sample company on the Frankfurt site, it would look like this:

49                           country code
69                           Frankfurt area code
000                         Company’s subscriber number
-0                            receptionist/auto attendant/corporate main phone number
-1000-4999          DID phone number range
-50000-50999     Non-DID phone number range
-5100-7999          DID phone number range
-80-89                   Cross-site prefixes
-9000-9999          DID phone number range

In the previous blog article OCS 2007 dialplan fundamentals the way to make the DID-phone numbers unique was to expand the user’s phone number to +<E.164> format so that corporate numbering plan matches the PSTN numbering plan. But what about non-DID phone numbers? What’s the correct way to fill in the msRTCSIPLine tel URI field? How to make these numbers worldwide unique as there might not just be an extension 50232 in Frankfurt but also on the other site in Hamburg?

There are – as always – multiple ways to solve this:

Using +<E.164 main phone number>;ext=<non-DID extension> format:

The recommended way for OCS 2007 which has already been mentioned on my friends Jens Trier Rasmussen’s blog would be to expand the phone number to a format that contains the corporate main phone number for the particular site in +<E.164> format followed by a prefix “;ext=” and the non-DID extension. In other words:

+<E.164 main phone number>;ext=<non-DID extension>

For our example the correct format for a Frankfurt non-DID user with the extension 50232 would like:

+49690000;ext=50232

And in the msRTCSIPLine attribute field (Line URI field in AD) you would need to enter:

tel:+49690000;ext=50232

+4969000-0 is the corporate main phone number of the Frankfurt site and 50232 is the non-DID extension of the user. By associating the non-DID extension to a particular site using the site’s main phone number, the non-DID extension became worldwide unique within the corporate telephone network.

Before using this format you have to make sure that in case you have connected a SIP Gateway between OCS Mediation Server and a PBX and you have remaining non-DID users on the PBX, that the Gateway is capable to eliminate the entire prefix “+49690000;ext=” before sending the called party number to the PBX.

For the Location Profile you have to make an additional regular expression rule that expands non-DID extensions to the format as presented above:

Pattern: ^(50\d{3})$
Translation: +49690000;ext=$1

For your convenience I have created an additional Enterprise Voice Route Helper file with an added rule to handle the non-DID phone number range 50xxx following this approach:

Using an arbitrary prefix to identify non-DID phone numbers:

Another option to make non-DID numbers unique within the worldwide OCS 2007 environment is to choose an arbitrary prefix for each site. An example would be +0001 for the first site, +0002 for the second… This procedure is only recommended if the Gateway or IP PBX that is connected to OCS Mediation Server is not able to handle the recommended syntax as presented above. You need to have rules configured on the Gateway or IP PBX that manipulate the called party number on outbound OCS calls by removing the arbitrary prefix and eventually replacing it with a DID main phone number.

Here is an example: A Gateway is connected between OCS Mediation Server and a PBX. An OCS user in Frankfurt dials 50232 in order to reach a non-DID PBX user on the same site. As the user has not been migrated to OCS yet, the call will be sent to OCS Mediation Server/Gateway. A normalization rule has been added to the Frankfurt Location Profile expanding non-DID phone numbers with a prefix +0001 (e.g. +000150232) that represents the Frankfurt site. On the other hand a rule has been configured on the Gateway that eliminates the prefix before sending it to the PBX so that on the PBX just the extension 50232 arrives. Downside of this procedure is that for every site you should have a dedicated prefix and you have to keep a manual translation table matching prefixes to sites.

The regular expression that needs to be added to the Location Profile when following this approach looks like:

Pattern: ^(50\d{3})$
Translation: +0001$1

For your convenience I have created an additional Enterprise Voice Route Helper file with an added rule to handle the non-DID phone number range 50xxx following this approach:

Using the subscriber number as arbitrary prefix to identify non-DID phone numbers:

The last option is to use the local corporate subscriber number (+4969000 in our example) in order to create a fake +<E.164> format number to handle non-DID extensions. This procedure is also just recommended in those situations if the Gateway or IP PBX that is connected to OCS Mediation Server is unable to work with the “main number ;ext=” prefix. The advantage of this procedure compared to the procedure above using an arbitrary prefix is that you only need one rule on the Gateway to remove +4969000 as a prefix before just sending the 4- or 5-digit extension number to the PBX/IP PBX.

The regular expression that needs to be added to the Location Profile when following this approach looks like:

Pattern: ^(50\d{3})$
Translation: +4969000$1

For your convenience I have created an additional Enterprise Voice Route Helper file with an added rule to handle the non-DID phone number range 50xxx following this approach: