I’ve seen various customers that were building OCS dial plans that did not comply with our recommendation to follow RFC 3966. Some of these customers had problems while I was engaged with them. All the rest will have problems later.
Note: RFC 3966 is the standard related to specifying a “tel” URI. It is the reason OCS uses E.164 global numbers prefixed with a plus sign. Because E.164 is easier to say than RFC 3966, some (including me) will use the former term when the latter is more correct.
Phone numbers in OCS are different from phone numbers in a typical PBX because they are based on a enterprise-wide directory. A user from any location in your organization must be able to look in the directory and place a call to a user in any other location. Using local extensions or regional number formats is simply not an option in the directory.
I want to encourage you to “think big” when it comes to designing your dial plan for OCS. You are probably integrating with a single PBX or gateway today. Superficially, it makes sense to build an OCS dial plan that accommodates the dial plan of the PBX.
What will happen when you want to integrate with a second gateway and perform least cost routing? What will happen when you move a portion of your telephony to a SIP trunking provider? Or, when your company expands into another country? Or, when you federate OCS with your business partners? Will the dial plan you design today still make sense then?
Specifying Phone Numbers in OCS
The diagram below depicts the high-level operations performed on a phone number entered by a user in OCS. The core of these operations should be based on standard tel URIs. Only at the input and output of this process are other dial strings appropriate.
The Line URI is a tel URI and should follow RFC 3966 which is the standard specifying the format for tel URIs. It follows then that a normalization rule should result in a number that complies with RFC 3966. Similarly, a route decision should be based on numbers that comply with RFC 3966.
(Notice that the above picture is only intended to show what happens to numbers that the user provides. Phone numbers can also be provided by federated partners that were normalized by their rules but must be routed according to your voice policies. That alone demonstrates why following standards here will be so important.)
These things should not be in your normalized numbers: PBX steering codes, trunk access codes, authorization codes, international dialing prefixes, or anything that is not related to the normal form of the user’s phone number. If they are, it will cause problems with reverse number lookup, click-to-call dialing, international calling, least cost routing, and federated partner numbers.
I have seen a U.S. number normalized to something like +912065550100. Nine is a common outside line access code here in the U.S. and some people want to put the access codes into their normalized numbers so that the mediation server will send that to the IP-PBX. However, this will cause problems for reverse number lookup and for routing calls to India that has country code 91.
I have also seen numbers normalized to extensions like +8632. The ‘+’ sign signifies a “global” number and this is clearly not one. If the user has a DID, simply use that for their phone number specified as a full E.164 number. If not, options are provided by the RFC for specifying the extension with a DID number in a format like +12065550100;ext=8632.
Leaving off the country code assuming that you’ll only have to deal with in-country calls is equally wrong. I cringe when I see +2125550100 unless we’re referring to a number in Morocco.
If you build your OCS dial plan with anything less than E.164 today, then you limit your growth options later. Perhaps you have only a single mediation server connected directly to your corporate office PBX today. But, what about when you add a mediation server connected to the PSTN or PBX in another city or country where the numbering plan is different? Using E.164 in OCS lets conversion to locally-appropriate formats happen at the local gateway.
Similarly, not using E.164 will limit your ability to add SIP trunking. One deployment option with significant cost savings potential is to deploy OCS with two mediation servers: one connected to your PBX via a gateway for internal calls and the other connected to a SIP trunk for low cost external calling and new incoming DIDs. You’ll need to be using E.164 for that type of routing.
If you federate with any partners, the presence information that you receive from them and that you send to them will include normalized phone numbers. Your user policies and routing must be able to handle their phone numbers. (And, conversely, their routing must be able to handle the normalized phone numbers you are passing to them.) If your (and their) OCS dial plan is not based on E.164, this will be problematic, at best.
Some may feel limited by this reliance on E.164 within OCS; I consider it an advantage. Routing is performed without consideration of the local format required to place the call. This is what provides the great flexibility in what you connect to the mediation server because your OCS dial plan does not need to accommodate any distinctions between gateways, IP-PBXes, or SIP trunks. The conversion to a locally-relevant dial string can be done where the local knowledge exists.
Ultimately, using global numbers makes your OCS dial plan much simpler than previously possible with an enterprise-wide PBX deployment. You could say this is another reason we don’t refer to OCS as an IP-PBX – it’s not a private branch exchange. It’s a distributed unified communications platform and demands a dial plan that recognizes that.
This post has been brought to you by the letter E and the numbers 1, 6, and 4.