Brief History of UC

Before Voice over IP (VoIP), voice calls were sent over a dedicated network. Each call passed through a dedicated circuit and was switched from one point to the other, hence the term circuit-switched. Although this guaranteed a quality connection, it required dedicated processing power and physical connectivity. For example, the wire that went from your home telephone to the central office (CO) connected you to a physical port on the CO telephone switch. The processor of the CO switch had to constantly monitor each port to determine whether a particular phone (port) made a request to dial a number or access a feature, such as call forwarding.

With a telephone connected to a dedicated network, either the public switched telephone network (PSTN) or an enterprise class private branch exchange (PBX) network, it was difficult for outside influences to affect the quality of a connected call. Although having this separate network held numerous advantages, most notably quality and reliability, individual PBX or CO switches used proprietary protocols limiting interoperability and feature expansion. It also meant, for example, that if you wanted to access your PBX voicemail box from your email client, you were subject to the whim of the PBX voicemail vendor’s decision as to what you could and couldn’t do and what standards were supported.


Using LANs and Packet-Switched Networks
As more and more communications began using LANs and packet-switched networks (the Internet is just a huge packet-switched network), the voice networks were forced to open up and connect to other networks. Unified messaging was probably the first mainstream attempt at UC. Accessing voicemail from your email client and unifying your inbox gave users the potential of true UC. In fact, some traditional phone vendors still consider unified voice messaging the equivalent to UC. Of course, anyone who has shared a desktop with a single click, made a call without dialing a phone number, or created a conference using only the mouse certainly knows that is not the case.

The capability to leverage a database of phone numbers to make calls using the phone was also an early attempt at UC. Anyone who attempted to deploy this type of integration, even as recently as a decade ago, knows that it’s not for the faint of heart and was generally implemented only in narrow cases, such as when a huge database of contacts were dialed by large calling centers. The average enterprise had neither the expertise nor the time and money to implement such a system.


VoIP Becomes Mainstream
When VoIP finally became mainstream, again, the promise of truly UC was presented to the enterprise community. In theory, now that the voice packets were riding the same network as the data packets, how difficult could it be to unify them? A lot harder than it looked.

Although VoIP brought the capability to easily perform day-to-day administrative tasks such as moves, adds, and changes, little was done to unify the communications. Users’ identities were still synched from, and stored outside of, the VoIP PBX, voicemail systems still use proprietary interfaces, and now the quality of the voice call was subject to influences outside of the PBX administrator’s hands. It seemed that, aside from adding complexity to the building of a communications system, VoIP didn’t add that much value overall.

As a new technology, most of the effort in deploying VoIP was put into the actual engineering and the proper deployment of the technology, not in the leveraging of the endless possibilities that existed. In addition, VoIP was initially positioned as a replacement end state for the traditional TDM infrastructure. Enterprises that saw cost savings over dedicated point-to-point (T1) links saw value in VoIP-compatible PBXs, but just replacing the line cord that went into the desktop phone with an Ethernet patch cord didn’t alter the user experience much.

Users still had to remember phone numbers, dial a multitude of phone numbers to reach someone, leave and retrieve voicemail messages using the handset, check multiple voicemail inboxes, and so on. Communications were unified simply because they were using a VoIP-based communications system.

To truly unify communications, begin with a central repository of user attributes at the core of your strategy. This repository should be easily updated, secure, and extensible so that as new features are created, the required attributes can be easily added. If an enterprise has deployed a Windows server infrastructure, it already has a repository in place: Active Directory.

Unlike other solutions, Microsoft’s UC architecture directly uses Active Directory and does not rely on a separate data feed for synchronization. Unlike previous versions, Lync Server now utilizes a Central Management Store (CMS) for all settings and configuration details. This store is replicated to all servers so that servers are now survivable.

Source of Information : Pearson-Microsoft Lync Server 2010 Unleashed