Combining a bare-bones PBX system with one or more services or products for UC capabilities and virtual numbers can result in a very powerful solution.

Over the past decade, the phone system business has changed dramatically. It changed from TDM to VoIP, from hardware to software, and from switching to unified communications (UC). The changes are not slowing. Traditional phone systems are threatened by cellular carriers, SaaS solutions, and non-traditional alternatives such as Skype and other peer-to-peer offerings as well as enterprise server based solutions.

User requirements and expectations continue to increase. Enterprise customers demand more features, more integration, more flexibility, and more manageability; all at lower costs with a quicker ROI. The voice component of overall communications may be shrinking, but quality voice systems remain a critical component to the enterprise comms puzzle.

The traditional switch vendors have largely developed server based applications to enhance their core switching platforms with modern UC capabilities. A similar pattern emerged among the players; multiple servers for each application consolidating into fewer servers with an increasing independence from the core switching functions. This independence is possible as a result of separate platforms, the increasing popularity of SIP, and the need to integrate with multiple systems and serve multiple locations.

Many of the switch makers are now positioning their UC products as a value-add to existing "legacy" systems rather than replacements. This makes sense given the current economic climate, and generally centers around the virtual number feature. This model effectively separates key PBX/UC intelligence (AKA applications) from the switching core. Drawing a boundary between the phone system and advanced phone features allows users to consider a variety of solutions rather than limit themselves to the incumbent switch maker or to any one PBX manufacturer.

It is a very interesting concept, and one that can apply to green field implementations as well. A brand new cutting edge UC solution could make sense to start with a bare bones on-premise PBX. A bare bones PBX is defined to possess the following core phone features: hold, transfer, redial, speaker, speed dial, and name/number display. The switch itself must support common features such as intercom, paging, PRI, T1, and ideally SIP trunking. No advanced features such as ACD, voice mail, or even redundancy. Most vendors offer such a product either as a separate model or as a bare-bone version of their primary platforms with minimal licensing. These base systems are relative bargains compared to their full-featured brethren.

It is worth noting that this bare-bone PBX could even utilize digital phones. It is a common misconception that VoIP phones are required for advanced features--most “VoIP” features are implemented on the switch itself or the desktop computer; not the phone. Other than the micro-browser, modern IP phones really don’t offer any additional functionality over their predecessors of the past 20 years--and few users actually utilize the micro-browser. VoIP phones are attractive since they enable a single network for management and reduce costs associated with moves. Digital phones should not be ignored though--they cost less and can utilize existing wiring and simplify LAN design.

The typical user will now have 2-5 private numbers such as their direct dial number on the bare-bone system, their mobile number, and perhaps their home number. The virtual number feature provides one public number that routes incoming calls based on user defined criteria--all or some private phones could ring depending on the rules. This is one reason why redundancy wasn’t important on the bare-bone system (it is important on the virtual number server), as calls can be routed to different locations should a problem arise. Call routing rules can determine routing based on time of day or even by who is calling (call screening).

The virtual number solution works very nicely for incoming calls, but outgoing calls pose a problem. The issue is the model falls apart when the private numbers become public; typically via outbound caller ID. Once people start directly dialing the private numbers, the value of the virtual number solution is lost. Multiple work-arounds exist, but the easiest/seamless solution is to just be able to pick up the (office) phone and dial. This can be accomplished with equipment and carrier choices that allow caller ID substitution (fairly common feature set with T1, PRI, and SIP trunking). Outbound calls from the bare bones system should send out the public direct dial number.

But the stated goal was a cutting edge UC solution. That definition requires some or all (even most?) of the following components:

* Presence
* Unified Messaging
* SIP
* Mobility component
* Fixed Mobile Convergence
* Instant Messaging
* Conferencing (voice and/or video)
* Collaboration

All of these components are readily available from one or multiple vendors. The bare-bone PBX provides core infrastructure including physical phones. The UC components can now be added. A UC solution including the virtual number service can be obtained/implemented in two basic ways: purchase the solution or as a service subscription. There are combinations and permutations of these two methods. An owned solution (from one or multiple vendors) can be implemented on-site, in a co-lo facility, or even in the cloud. The service can be purchased from a single provider or numerous specialized providers. Or, it can be a mixture of some on-premise and service based solutions such as owned/managed Microsoft OCS servers integrating with a SIP/UC service.