Welcome to The Modality Systems Blog

I spend a lot of my time working with our clients to help them design and deploy OCS infrastructure.  We’ve thought about trying to develop a “packaged” design, but it’s nearly impossible in a generic way because each client has different needs and requirements.  Each is trying to solve a unique business problem, has a unique geographic topology, a different budget, is subject to different laws and regulations, etc. 

We usually start with a workshop, which is essentially an interview and educational discussion.  In each case, the questions we ask are the same.  The following list is not exhaustive, but if you sit down and work through each of these areas, you will have a good set of data as input to your design planning.   

Overview

Microsoft Office Communications Server 2007 provides organisations with a number of integrated features to enhance and simplify communications. OCS 2007 integrates Instant Messaging, Web Conferencing, Desktop Audio and Video conferencing and Voice (telephony) capabilities.

It’s important to understand that the IT environment and infrastructure required to support real-time applications is fundamentally different than that required to support non-real-time applications (such as file sharing, email, printing and web applications.) The following is a list of important topics to consider when deploying an OCS 2007 solution.

Determine Feature Requirements

Not all features of OCS 2007 must be deployed. The product is designed to support a modular or phased approach for deployment whereby you can choose to deploy only certain features, or deploy features over several stages. The fundamental building block of all OCS deployments is the Instant Messaging and Presence capability.

The optional or modular features include:

• Web Conferencing
• Audio and Video Conferencing
• Telephony Integration (remote call-control)
• Enterprise Voice

Your OCS 2007 high-level design should specify which of the features are required for a particular deployment or set of users.

Determine Scenario Requirements

Likewise a variety of scenarios (or “topologies”) can be deployed. Does your organisation only require internal user access while users are on the corporate network or VPN? Or do you require capabilities which extend the reach of the features to external users and federated companies?

The most common scenarios include:

• Remote User Access (Giving your users access from the Internet without a VPN). 
• Federation with other companies (if so, which features will be supported over federated links?)
• Federation with Public IM networks (aka Public IM Connectivity)
• Anonymous or Authenticated external Web Conferencing Access

Plan for Geographic Location of Infrastructure

LCS2005, the predecessor to OCS 2007, lent itself to centralised deployments.  Global companies would often deploy a single pool of servers to service the entire global user base.

OCS 2007, however has new features which require more planning and analysis when considering the physical location of the infrastructure.  Although the Web Conferencing, Audio/Video Conferencing and Voice capabilities use well-tuned codecs that operate in a range of network conditions, the best approach for a high-quality user experience is to give your applications the “network that they need”.

This means that for organisations that are geographically dispersed, OCS server infrastructure should be deployed locally in offices where larger concentrations of users exist. The goal of the topology planning discussions should be to reduce unnecessary WAN usage, not only as a cost saving measure, but to provide higher-quality user experiences.

In the case of voice deployments, well-planned topologies can provide local PSTN “break-out” connectivity in regional and branch offices. This technique keeps voice calls on the internal corporate IP network as long as possible, ensuring that only local toll charges will be incurred in many cases.

Assess Policy, Compliance and Security Requirements

Policy and compliance requirements in your organisation may derive from local or regional law, industry-specific regulations, internal usage policy as determined by the business, or other forms policy that are in place to guarantee basic record keeping or conversation traceability.

It is important to realise that OCS 2007 provides several different modes of communication and each of these modes may have different policy and compliance requirements. For example, you may need to archive all Instant Messaging traffic, but not web conferencing content. Or you may want to keep call data records for only voice conversations with external parties, but not internal calls. Maybe archiving is not required at all, but certain departments in your organisation should be isolated for security or regulatory compliance reasons.

Determining the policy, compliance and security requirements during the design phase can have an impact on the features you choose to deploy and the method or timing with which you choose roll out these features. You may need to evaluate whether to deploy the archiving functionality included with OCS 2007, or to deploy archiving solutions from 3rd party companies which provide additional capabilities and can integrate with any existing archiving storage technology that you may already have in place for other applications.

Ensure that Infrastructure Pre-Requisites are met

OCS 2007 relies heavily on the use of Microsoft Active Directory – as a directory of users, an authentication and authorisation engine, and for management tools and infrastructure. It is worthwhile to perform an assessment of your AD to ensure that it meets the requirements and is operationally healthy.   If you need to get change-control approval for AD modifications, make sure to budget enough time for this in you schedule.

Also, access to a Public Key Infrastructure is an important pre-requisite for OCS 2007. All OCS servers communicate securely using Mutual TLS for authentication and encryption and this relies on the deployment of PKI certificates to all OCS servers.

If you require consistent availability of the OCS 2007, your design can mitigate against hardware failures by using Enterprise Edition pools. These topologies require hardware load balancers and optionally SQL clustering technology to be deployed.  If you plan to use existing HLBs and SQL Back-End storage infrastructure, ensure that the required performance and capacity is available for your deployment.  

-John Lamb, Modality Systems Ltd.

A Guide for Enterprise IT Decision Makers

We’ve developed the following tenants to keep in mind when evaluating or implementing a UC product or solution in your company.   A good UC strategy will will address all of the tenants in a way that meets your business needs.  

1.  Strong Identity Management

A user’s Identity must be authenticated and enforced by the back-end system.  One of the many advantages of the current telephony infrastructure is that its extremely difficult to spoof identity.   Short of stealing someone’s phone (or mobile SIM card) it’s nearly impossible to appear to be calling from a phone number that you don’t own.   With a UC device-identity portability infrastructure (see our post on “What is Unified Communications”), both the sender/caller and the receiver must be authenticated in order to prevent identity spoofing.  Once authenticated, the user’s display name should system-defined rather than user-defined to ensure professionalism and appropriate identity use. 

2.  Security

The UC infrastructure must systematically incorporate security features.  Another advantage of the current telephony infrastructure is that it’s inherently very secure from inappropriate access and misuse like wiretapping, interception, replay and redirection attacks.   This can be addressed in a UC system using well-known security techniques.  Encryption should be used at every hop in the communication (for both signaling and media traffic).  Authentication must be enforced, not only for users, as mentioned above, but also for system to system (server to server) communication.   

3.  Network Abstraction

The physical and network layer infrastructure should be an abstraction.  The network must be there and it must have certain characteristics, so it can’t be ignored – but, the details of it’s implementation can be abstracted.  This allows the UC solution to work across different networks without significant changes to the user experience.  A user should have the same experience whether connected to a high-speed corporate IP network, a branch office, a hotel wireless access point, GSM, 3G, WiMax, or the PSTN. 

4.  Device Abstraction

This is a similar concept to what is discussed above in the Network Abstraction section.  The devices are critically important, but the fundamental experience should not change from device to device.  The video conferencing experience on a PC at your office (or in a specially designed video conferencing suite) will be radically different from your experience on a mobile phone, but the user entry points for communication should remain consistent and intuitive.   Software based solutions are the best way to ensure a consistent experience since the user interface can easily be made portable. 

5.  Encompass both mobile and non-mobile scenarios.

Any service deployed only to the edge of the Enterprise will have limited usefulness in the modern world of mobile workers.  Various devices and techniques are now readily available that enable NAT and Firewall traversal of real-time multi-media traffic such as Session Border Controllers (SBC’s) and media relay servers that incorporate technology like the Interactive Connectivity Exchange (ICE) protocols.  These can enable the UC solution to work from any location with a basic Internet connection.  Recent improvements in media codecs also mean that high-quality bandwidth at the edges of the network is no longer essential for voice and video calls.  

6.  Simplify the user’s experience 

Using Presence:  One of the major benefits of a UC solution to simply the user’s experience and enhance a user’s productivity.  The keystone of any modern UC system is “presence”, which enables the caller to have information about the contactibility state of the recipient.  Gurdeep Singh Pall of Microsoft likes to say “Presence is the new dial-tone” and this is absolutely true.  Why bother calling someone if you know ahead of time that they’re on the phone? 

Using a Friendly Identity Format:  A UC solution that provides a URI-based identity schema (e.g., the user-friendly user@domain format) is also a big step in the right direction.  Anything that uses phone numbers as the primary user ID or replicates the 3 x 4 telephone keypad on a computer screen as the primary user interface should be a red flag. 

7.  A Platform

Finally, a UC system should be a platform.  That is, it should have a rich set of API’s and protocol-level interfaces that allow developers and systems administrators to connect it to other systems that know nothing about UC.  For example, your UC system should integrate seamlessly with your company’s electronic directory and line-of-business applications through simple and straightforward API level integration.   We should also be able to extended the capabilities of the platform using customised software (such as like developing call-center applications or automated agents) and devices (like hooking up advanced video conferencing hardware).

-John Lamb, Modality Systems Ltd.

From a terminology perspective, the concept of “unified communications” is currently at the center of a swirling vortex.   To some extent, this is because the term itself is overloaded, but it’s also because there are actually a lot of moving parts that are intersecting in fascinating but complex ways.   In order to develop a definition, we need to explore the constituent parts, and  from there we can begin to get idea of what we are looking for in terms of an overarching concept or strategy.

Network Convergence?

If you make or sell networking equipment, the word “convergence” is used a lot in conjunction with UC, and the two terms are sometimes interchangeable.  From this viewpoint, we are looking specifically at convergence of the network layer, whereby voice and data traffic will travel over the same IP infrastructure.  This can of course be extended to include not just voice, but any real-time traffic such as text messaging and video conferencing.

The general consensus is that network convergence is the inevitable conclusion in both Enterprise and Carrier networks for the simple reason that there is a lot of opportunity to generate significant cost savings by converging data and legacy telephony networks.  These cost savings are driven not only by consolidation of infrastructure (which has direct impact on COGs and installation costs), but also consolidation of operations and maintenance (which are more indirect “ROI” type cost reductions).  

Network convergence will dramatically change the economics of the of the underlying communications network infrastructure.  However, equivalent changes in end-user experience do not necessarily follow.  If the goal is to unify communications, network convergence is a good and necessary tactic, part of the strategy – but not the strategy by itself.   

Device Convergence?

If you make or sell end-user devices and software, such as mobile phone handsets, desk telephones and PC’s, again “convergence” of features and functionality becomes important at the endpoint.  The mobile phone I use today is capable of delivering email, voice calls, text messages, pictures and downloading and listening to music.

We have these smart devices, but they also exist alongside less-than-smart devices like traditional telephones.  They also exist alongside much smarter devices like PC’s and laptops, which provide far greater capability and better user experience, but at the expense of portability.  

Do users want convergence of the end-point?  Maybe.  The argument for device convergence is strong in the case of mobile devices, especially when the user is traveling away from home or workplace.   The obvious benefit here is the portability and simplicity of feature access, but it usually comes at the expense of the feature’s fidelity.  Video conferences and spreadsheets will always look better on a big screen.     

For non-mobile devices, the case for feature convergence is far more suspect.  I’ve yet to see anyone seriously get excited about using the index card-sized screen on modern business telephones.   Factory floors and building lobbies aside, any user that has a US$500 (£250) phone on her desk will also have a PC with a 19″+ LCD screen.   Would she want to view data or images on that gorgeous new LCD monitor – or on the small and pixilated telephone screen?  For me, the choice is clear.

Software (and the Device-Identity Portability Problem)

If you make or sell software, much of the UC world is about gluing communications channels together in clever and intelligent ways.  Microsoft, Cisco, IBM, Nortel and a host of other vendors are now developing UC software for the Enterprise/Business market. 

When you approach a problem from a software point-of-view, two important things happen:  1.  It’s less expensive to make radical changes in the fundamentals of the approach when compared to developing a new hardware based system , and 2. A lot of lessons can be applied from similar software-based communications technologies that have tried this before, like email and instant messaging.

For example:  would you sign-up for an email service if they told you that you could access the account from only one device?  Would you buy a device that lets you access only one email account?  This concept seems ludicrous in the context of Internet based technologies, but this is what we put up with our current telephony infrastructure.  I have a phone at home, one at work, and a mobile phone.  Each device has its own phone number (identity) and without setting up complex call-forwarding options, each device can only represent that single identity.  

What if I could sign-in to any telecommunications device as both john@company.com  and john@personal.com.   I could have different communications profiles for work and personal communication – and I could get access to all of these communications (voice calls, voice mail, email, instant messages, and video conferencing) from any device.   So if I’m in a hotel, I should be able to sign-in to a phone as “me” and start making and receiving calls.   The “phone” could be something that looks like a phone, or it could be another device like my laptop.  If I’m on the road I should be able to use any of my mobile devices to do the same.

The Definition:

The trick is trying to distill all of the above into one sentence!  This isn’t 100% perfect, but a good start for discussion.

Unified communications refers to system whereby users can access all of their communications modalities (such as email, voice, voice mail, text messaging and video conferencing) from any class of device and from any location through a consistent and intuitive presence- and capability-based interface.