Business Opportunities in the UC Channel - Part 5

10 Apr 2012

This is the fifth of an eight-part weekly series of articles that leads up to the UC Summit 2012 that will take place May 6-9 in La Jolla, CA. See the UC Summit website for more details.

Last week we talked about the opportunity for the Telecom sales channel to add value to a UC deployment project by assisting customers in reviewing network bandwidth requirements and developing an optimal branch network strategy. This week we are going to cover the challenges of UC route planning and directory integration.

PBX systems each have their own directory structure; the primary key of which was the DID or extension number. Also contained in this system was a route table that stored the general routing rules as well as dynamic individual user preferences such as speed dial lists, forwarding rules, etc. Each PBX is a stand-alone system such that when a user moves from one office to another, the MAC (Moves, Adds, Changes) process required that the user be deleted from the PBX of the old office and added to the PBX at the new office. UC systems tend to be centralized, to greater or lesser degrees, in data centers and the addressing and routing mechanisms are entirely different, so this presents a significant challenge in the migration of a customer to UC. In keeping with the general theme of this series, in every challenge lies an opportunity.

The first thing that needs to be considered is the population of the UC system's central user directory. These are typically LDAP or LDAP-like data structures such as Microsoft's Active Directory. It is highly likely that such a system is already in place for the user of email and other systems that require authentication/log-in credentials. The addressing convention for email and UC is typically the same (i.e. 'user@domain') and it is important that this is retained as one of the great benefits of UC is the single user identity for all communications modalities. However, dependent on the UC vendor system requirements, there may be other UC system attributes that will need to be incorporated into this directory, one of which will be the user's telephone number.

The telephone number is required because each UC system will be required to be connected to the PSTN in some way. If the UC system is from a legacy PBX vendor, then the PSTN access is likely to be via the PBX itself. Whether or not the UC system is provided by a non-legacy vendor, the user directory will still need to map the telephone number to the user ID for situations where a UC "session" terminates or originates on a non-telephone device such as a PC and is terminating or originating a PSTN or PBX "call." The major work item is not the migration of the numbers, as this can normally be automated, even if it means dumping the PBX directory into a text file and manipulating it either manually, or through the use of scripting, ready to be uploaded into the new directory. The main challenge is in normalizing all of the numbers.

Imagine an enterprise with 9,900 users, based in 99 offices. It is probable that many of these users did not have a DID number, so only their extension number was recorded in the PBX directory. The likelihood that the enterprise, over the years, implemented a contiguous set of 4 digit extension numbers to the user base (i.e. 0001 to 9900) is very low. Some offices will have 2 or 3 digit extension numbers; some may even have 5 or more. The degree of overlap in all of these extension number sets will be significant; and this creates a problem in a centrally routed system. The determining factor in resolving this will be the number of connection points to the PSTN and the number of area code blocks that will be retained after the UC migration. This is a complex issue in itself and will be covered in part 7. Also affecting this will be the degree to which the UC system being implemented is a hybrid PBX/UC system. The UC vendor will provide clear guidance on this, but the specific customer implementation details will need to be resolved.

Another issue that needs to be addressed is the actual UC routing rules themselves. In some ways, a UC system is simpler in this regard because a user's device(s) of choice will self-register their IP address and the IP address is authoritative for routing; so, in general, roaming usage takes care of itself. Also, there may be user preferences that are self-administered, e.g. a preference to take voice calls on the desk set when the user is in their office. However, the complexities of system wide least cost routing for PSTN origination require that a rule base is defined. For example, a user that is normally based in New York who is trying to make a phone call while on a business trip to Paris to a local vendor should not be using the New York gateway to access the PSTN: this wouldn't have been a problem if the user was using a PBX system in the Paris office. Also consider emergency dialing - it would be bad if the New York emergency services were asked to respond to an emergency in Paris. Each vendor's system will implement this in slightly different ways, but suffice to say that the design of routing rules needs to be viewed from the lens of everything being routed from a central location for people who are now able to carry their communications device to wherever they need to conduct business and can get an IP connection.

We have seen that UC systems tend to follow the trend towards the centralization of infrastructure in data centers; and while that has its advantages, there are also drawbacks. One significant challenge of centralization is that it leaves the enterprise vulnerable to local outages at or near the central site that will impact the entire enterprise: so next week we are going to cover disaster and failover planning.