Over the last few days, I’ve been describing the Microsoft view on Unified Communications (UC), based on a presentation given recently by James O’Neill.

In the first two posts in this series based on James’ presentation, I outlined the business need for unified communications and some of the Microsoft technologies that can be used to address those requirements before examining some of the benefits to be gained thorough adaptation of communications to fit modern working practises. In this third post in the series, I finally move on to the technology, looking at the main steps involved in implementing a UC solution using Microsoft products.

It may also help to check out my post from April 2006 which provides an introduction to voice telecommunications for IT professionals.

In a traditional communications infrastructure, voice and data networks are managed independently:

Even though there has been a move to replace telephone cables with standard CAT5/5e/6 cabling in recent years, and IP telephony has become more commonplace so there has been some convergence at the network level, the voice and data systems are typically separate (although their directories may have been integrated).

Implementing Exchange Server 2007’s unified messaging capabilities allows the removal of the PBX voice-mail system and provides voice-mail, fax and speech capabilities within Exchange, accessible via standard e-mail clients, Outlook Web Access or through a voice call:

To enable the integration with the PBX, a VoIP gateway may be required (some PBXs may integrate directly).

Replacing any existing instant messaging systems with Office Communications Server (OCS) 2007 (or implementing OCS as a new service) can provide VoIP connectivity with the existing telephony systems, enabling both “soft” and “hard” IP phones to be used. In addition, Live Meeting can be used to provide conferencing facilities:

With this infrastructure, OCS will integrate with Exchange and work collaboratively to route calls, present caller ID information (used in the subject of messages), perform directory lookups, etc. but for OCS to integrate with a PBX a gateway is required. A basic gateway also requires an OCS Mediation Server to be deployed whereas an advanced gateway includes the necessary technology to integrate directly with the PBX.

Effectively, there a four levels of integration:

1. None at all.
2. Basic gateway with mediation server.
3. Advanced gateway.
4. VoIP capabilities built-in to PBX.

Microsoft has partnered with a number of manufacturers to provide hardware that integrates with OCS, and the strategic gateway partners are Audiocodes, Dialogic and Quintum.

This approach allows legacy routers, gateways, PBX and phones to be maintained (after all they are a significant investment) but integrated with software solutions to adopt new ways of working, as featured in Microsoft’s VoIP as you are campaign. For organisations that are ready to remove the legacy telephony altogether (e.g. in a green field site) an advanced gateway can be used to integrate the VoIP system with public telephone networks:

The call path is as follows:

• User initiates a call.
• OCS looks for valid endpoints and sends a packet to say that there is an incoming call (including call forking, if configured).
• An endpoint (possibly voice-mail) accepts the call and the server drops the other connections.
• Once the call is established, the server drops out of the conversation (aside from logging the call details) and the call continues on a peer-to-peer basis.

There are a few additional points to note:

• Where network address translation is in use, an OCS Access Proxy may be deployed.
• If the call is routed over the PSTN, the gateway is just another party on the call (as if it were a phone).
• In a conference scenario, Office Communicator clients only have a single channel of data in each direction and so where multi-party calls are placed, a media control unit (MCU) is required to act as a negotiator. At this point, the direct call is dropped and a new multi-party call is set up via the MCU. Live Meeting clients can send multiple video channels (plus sound and desktop conferencing on separate channels).

Having outlined a VoIP-only solution, it’s often the case that the legacy infrastructure cannot be completely removed – there are still some limitations around VoIP that OCS cannot address (at least not in the current release). For example, if there is a loss of power, then there are no network switches and there is no telephony (the same issue also applies for IP Phone systems using Power over Ethernet – such as Cisco IP Phones). As a consequence, and to meet health and safety requirements, it may be necessary to retain some traditional telephony infrastructure for emergency calls. Even if they are accessible through OCS, emergency calls present another challenge in that the call will be placed at the gateway, which may be in another city, country, or even continent to the person making the call, so dial plans need to be carefully designed.

Clearly this post is heavily biased towards Microsoft products and another major player in the unified communications space is Cisco. In the next post in this series, I’ll take a brief look at the approaches that the two vendors have taken to unified communications (and it will be a brief look, as I have very limited Cisco experience!) before I wrap the series up with some notes from my own OCS implementation last year.