Unified communications are like relationships. We all want ‘em, we all have ‘em ... what do we do with ‘em? (with respect to Jimmy Buffet for that one). In all seriousness, you should ask yourself some important questions regarding unified communications:

In this chapter, we will explore these very questions, and help you come up with the answers. Because this book focuses on Microsoft technologies, we will also look at many of the Microsoft products that have brought us to the present-day solution that we will be focusing most of our attention on in this book: Office Communications Server (OCS) 2007.

Before we look forward, it’s a good idea to step back and look at how we got to “today.” To begin, we will review the progress and history of communication over the past 150 years, and how it has impacted where overall information delivery and communication are going.

You can breathe a sigh of relief. We’re not going to take you all the way back to the caveman and discuss cave drawings. Likewise, Egypt and those amazing hieroglyphics are out. We’re going to jump in right around the time of Mr. Alexander Graham Bell. Way back in 1876, Mr. Bell (not Antonio Meucci, as some conspiracy theorists believe) invented the first telephone (Figure 1.1), which was based on the same principles of the telegraph, which is essentially the transmission of wire signals over copper wiring. Bell spent numerous hours attempting to transmit sound over this medium, first in the form of a clock spring’s twang, and then, on March 10, 1876, finally speaking those now-famous words, “Mr. Watson—come here—I want to see you.”

Figure 1.1. A Replica of Bell’s First Telephone

Over the next 100 years, Bell’s invention would grow in popularity, ultimately ending the reign of the telegraph and eventually placing a phone in nearly every home within the developed world. Over the years, the shape, style, and price of the Plain Old Telephone System (or POTS) would change many, many times. It is important to understand that the result of this invention was the intercontinental mesh of telephone wires. These old “POTS lines” are the basis for why we have digital communication today.

If Bell’s invention provided for the foundation of modern-day communication, the invention of the Private Branch Exchange (PBX; Figure 1.2) is the ground floor. Although the acronym “PBX” has been around since the days of the operator-assisted telephone call, it is generally used when referring to corporate telephone systems. The first readily available PBX solution was released in the early 1970s and comprised four core components:

Figure 1.2. A Legacy PBX System

Basically, when a call was placed from a user station (keep in mind that a station can be a phone, an analog device such as a modem, a fax, and so on), the PBX is responsible for completing the call to either another internal station or the outside world via the Public Switched Telephone Network (PSTN)—“Ma Bell” in the early days, and the “Baby Bells” in the 1980s and 1990s. We are oversimplifying the call process, as a number of factors play into it, including Class of Service, or COS (does the caller have the right to place this call); Least Cost Routing, or LCR (which phone line is the least expensive to make this call); and many other pieces of the calling puzzle, all determined in milliseconds. The problem with the PBX was that it was massive in size and ran hot enough to keep an entire Alaskan community warm on a subzero day.

Although arguments could be made for satellite communication and cell phones, the next great revolution in Internet Protocol (IP) communication was the invention of the IP-PBX. A company called Sphere is generally recognized as the inventor of the IP-PBX; however, it decided to go with Asynchronous Transfer Mode (ATM) communication as opposed to IP. As such, the real revolution in IP-based communication came in late 1998–early 1999, when it was determined that “network convergence” could be provided over existing Ethernet implementations. The first IP-PBXs were incredibly crude, using IP-ready phones that plugged into any Ethernet port, without any focus on the quality of the call or the effect of data transmission on it. We will spend a lot more time discussing IP communication in the next section.

So far, we have spent this chapter discussing voice communication. However, we also need to spend some time discussing software-driven communication.

Software Communication

Although voice communication had a pretty big head start on software communication, any fool can see that software (or data-based) communication has made a fast and permanent impact on our society. We could spend time discussing many avenues, including services such as CompuServe (Figure 1.3) or community-owned Bulletin Board Systems (BBS), or go down the road of the “early” Internet, but the real boom in terms of software communication for both the business world and personal communication was the “Dot Com” boom of the late twentieth century.

Figure 1.3. A Screenshot of the Early CompuServe Service

While many larger enterprise-type companies had already implemented internal-only mail solutions, the rest of the business world was pretty much left out in the cold regarding data communication. As dial-up Internet began to grow in popularity the “chosen few” were allowed modems (or, if you were really high-tech, you may have had a server with a modem bank) to go out and get e-mail on behalf of their company.

Likewise, instant messaging (IM) had just begun to pop up as a “cool” new way to communicate with friends and family. Although purists would claim that the UNIX operating system really offered the first IM communication (as many BBSs did), companies such as Tribal Voice (Pow Wow; Figure 1.4), AOL (AOL Instant Messenger/AIM), and ICQ began to pop up all over the place. Again, at first IM was really nothing more than a “gadget” that was used in home environments, and it was generally looked down upon in the corporate world.

Figure 1.4. PowWow Instant Messaging Screenshot (from Wikipedia)

By the latter half of the 1990s, high-speed Internet as well as corporate Internet-capable e-mail was being implemented at a rapid rate within corporations around the globe. The Dot Com boom (it feels funny to say that, doesn’t it?) was really beginning to pick up steam. Venture capitalists everywhere were throwing their money down the drain by the bucket load, funding startups that had absolutely no idea what to do with all their newfound cash! Religious battles between different mail solutions such as Microsoft Exchange, Lotus Notes, Novell GroupWise, and various open source mail solutions were beginning.

At the turn of the millennium, something pretty astounding happened: Investors recognized the fact that they weren’t getting much (any?) ROI and started to pull back funding to these startups. However, a very interesting side effect to this Internet “boom” took place: the birth of true Voice over IP (VoIP) communication.

Anyone familiar with early VoIP can tell you fireside stories about the lack of quality, due to many reasons including packet delays, lost packets, and packets that arrived out of order. However, as companies (both vendors and end-users) really began to think about the potential cost savings of integrating systems, more innovation regarding IP communication began to occur. Although many traditional PBX providers, such as Lucent/Avaya and Nortel, initially laughed off the idea of integrated solutions, “data” companies such as 3Com, Cisco, and Alcatel took off as the “leaders” in this space. Thanks to some very wise acquisitions and a lot of research and development funds—plus the added bonus of owning most of the network infrastructure worldwide—Cisco really took off as the market leader in VoIP. To understand how VoIP works, we have to take a slightly deeper dive into the core components of a VoIP solution. The first thing to discuss is something we’ve already talked about: the switching mechanism.

Switching in the Voice World

If you think about how you make a phone call today from your home, some basic steps need to occur:

1. You have to pick up the phone, regardless of how you do it; lifting the handset, pressing Speakerphone, and so on. The first thing you will hear is a dial tone. This means the central office (CO) recognizes the fact that you want to do ... something.

2. You dial a number, which the CO interprets and routes to the proper CO for the target, and ultimately rings at your intended recipient.

3. Once the other person answers the call (assuming someone or something is on the other end to do so), the circuit between you and the called party is “opened.”

4. When you (or the other person) hang up, the circuit is closed, and all lines associated with the circuit are freed up. Figure 1.5 shows a diagram of a phone call between Bob and Lisa.

   

   Figure 1.5. A Traditional Phone Call

It is important to understand that while this conversation is occurring—be it 30 seconds, 30 minutes, or 30 hours long—it’s always going to occur over the same circuit. In this scenario, we are always going to be passing some sort of traffic. It may be you speaking, the other person speaking, or simply background noise. This type of communication is known as circuit switching.

With data networks, we do not use circuit switching. Instead, we use packet switching. With packet switching, there is no need to pass traffic over the same circuit for a potentially endless period of time, much of which may be wasted time while no data is being passed. With packet switching, we can break up a larger piece of data into smaller “chunks” and distribute those chunks over an infinite number of paths. At a high level, here is how packet switching (Figure 1.6) works:

1. The first device—say, your laptop—is attempting to send a file to a file server. It breaks up that file into smaller packets (known as the payload) and tacks on the target system’s address information.

2. Your laptop then sends that packet off to its gateway (which may be a switch, a router, etc.), and assumes that the gateway knows how to deliver the packet. In turn, the gateway may deliver the packet directly to the server (assuming it’s on the same network segment), or it will pass it off to the proper next “hop.”

3. When the server receives the packet, it begins to restructure the file, much like a jigsaw puzzle—but with a specific set of instructions on assembly.

Figure 1.6. Packet Switching

So, what did this mean for voice communication? Well, basically, it meant we could do more with less. By that, I mean that by leveraging this method of distributing our transmission, we no longer had to ensure that we had a 1:1 ratio of potential phone calls to phone lines. On the internal cabling front (from the wiring closet to the desk), it also meant that we no longer had to have cable runs for both data and voice. However, adding voice onto our existing data infrastructure was not quite that simple. We needed to address a number of items, possibly the most important of which is the quality of the call being transmitted.

Quality of Service

Taking what we’ve said regarding packet switching, logic would tell us that conversations would be broken up into various chunks, arriving out of order. So, if Alexander Graham Bell were alive today, a conversation over VoIP would have come across something like “to see Mr. Wat—son here—I you. come want” instead of “Mr. Watson—come here—I want to see you.” Right? Wrong.

Early on, the early developers of VoIP were quick to grasp the idea that this wouldn’t work. Likewise, they were quick on the ball to determine that if a voice call over IP didn’t sound almost exactly the same as an analog call, it would never work. Therefore, they made a variety of “tweaks,” including adding “comfort noise” to the call, and other things to reduce unwanted problems such as “jitter.” One item was still outstanding in terms of voice transmission and the effect of the data network. This issue was related to the fact that nothing was stopping someone from transmitting a large file, streaming audio, and—oh yes—trying to make a phone call across the same 100 MB port. To address this, Quality of Service was born.

Whatis.com defines QoS as follows:

“the idea that transmission rates, error rates, and other characteristics can be measured, improved, and, to some extent, guaranteed in advance. QoS is of particular concern for the continuous transmission of high-bandwidth video and multimedia information. Transmitting this kind of content dependably is difficult in public networks using ordinary ‘best effort’ protocols.”

Basically, it comes down to the fundamental design of IP transmission—the fact that messages are sent using a best effort, and retries are often necessary to complete a transmission. As multiple data streams are passed over the same 100 MB pipe, each packet is, by default, given the same priority in terms of delivery. The obvious problem here is that in a voice conversation, a listener isn’t going to understand the conversation if a packet is repeated at the end of the message. QoS was particularly important for voice so that voice packets could be “tagged” and given priority in the data stream. Traditionally, QoS has been managed almost exclusively on hardware devices such as routers and switches. With the introduction of OCS 2007, Microsoft has taken this to the next level, taking call quality out of the hardware and developing Quality of Experience (QoE). We will discuss this later in the book.

Note

There are many ways to handle QoS, and various protocols are involved, which can often be further complicated depending on the hardware vendor involved. Unfortunately, an in-depth explanation of QoS is far beyond the scope of this book. However, if you are interested in learning more about QoS, consider picking up Administering QoS in Cisco IP Networks by Michael Flannagan (Syngress).

For many people, the concept of presence can be a little hard to grasp at first. Microsoft defines presence as “the ability of a person or device to communicate with others and to display levels of availability.” Quite often, when speaking with customers about presence, Microsoft assumes that IM is “presence.” However, this just isn’t true. IM is simply another way to represent presence. Many things make up presence, but any one item alone is not presence. Before we discuss what presence is, what it represents, and what it means in terms of business productivity, here is a list of some of the items that are a piece of the presence “pie” but cannot represent presence on their own:

In a face-to-face conversation, this is usually the point where people begin to look at me as though I’ve gone completely insane and should be rushed to the nearest medical facility. In particular, physical locale is usually the final nail in that coffin. At this point, I’m intentionally trying to confuse people. First, it can be quite a lot of fun if you do it right. Second, and more important, it gets them thinking and asking questions in their heads, if not directing them toward me. Anyway, why am I saying these key components of communication alone cannot represent someone’s presence? Because the fundamental concept of presence is communicating with a person. Take a moment to think about that.

If you were in your car on your drive to the office, and you needed to talk to one of your coworkers, you would not really be interested in determining whether your coworker was at his desk, on the road, at home, in a hotel, and so on. All you’d really want to do is speak to that person. How much time have you spent calling someone’s cell phone, desk phone, (maybe) home phone, and so on trying to reach him, and in the end leaving possibly three or more voice messages without ever reaching him? What’s even worse is when you leave those voice messages, simply to tell him that he needs to read an e-mail that you sent him! Talk about loss of productivity! In the end, it really should not be up to the caller to determine the best means to communicate with the called party. In some cases, communications problems can be easy to solve: Forward your desk phone to your cell phone or home number, right? Well, that can work in some cases, but what if you need to change the number you are forwarding to “on the fly”? For example, my cell phone doesn’t get great reception at my house, but I will often work out of my home office. At other times, I’m on the road and need that call to go to my cell phone, but I don’t want to have to go into the office to make that change.

By using a presence engine, we can control this call flow in a number of ways. First, we can implement and control basic call forwarding from a GUI console. In the case of Microsoft Office Communicator (MOC), this can be done on a PC or a Windows Smartphone, further extending your control of your presence—but we’ll get to that a little later. A true presence engine must be able to take this a step further, or we’re simply duplicating call control from a PBX. A presence engine has to be able to determine what to do with a call without you manually adjusting the call flow. For example, most of us keep our cell phones somewhere on our person, correct? Well, let’s say you’ve put in a few hours of hard work in front of your PC, and you decide to take a walk to the lunch room for a cup of coffee; the president of your company is also in there and decides to spark up a conversation that goes for 20 minutes. You know you have an important call coming into your desk phone shortly, but you don’t want to be rude. How great would it be if your PC could recognize the fact that you’re away from your desk, intercept the call to your desk phone, and forward it to your cell phone?

This concept loops back around to the fundamental concept of presence. In this scenario, the person who is calling you doesn’t want to have to worry about calling your desk, leaving a message, and then calling your cell phone. She wants one number to call. Why? Because she wants the most productive way to get in touch with you.

Presence in Other Applications

Presence in a single application (such as MOC) is fantastic, but you won’t be spending most of your time in front of the presence application. For everyone else, you will spend your time in various applications, such as Microsoft Outlook, or perhaps a CRM application or SharePoint portal site. Because we often have multiple applications running, it’s important to be able to extend presence into these “presence-aware” applications. In some cases, we can even add presence into applications that are otherwise not presence-aware. The benefits to this can be pretty astounding. I mentioned Microsoft Outlook earlier—if you were to survey 100 service-oriented employees, you would probably find that the majority of them would agree they spend most of their time in front of e-mail. For many of us, it’s also the first thing we check when we wake up in the morning and the last thing we check when we go to bed. With presence integration, we can gather a lot more information about the sender and recipients of the message (Figure 1.7). How beneficial would it be, at 11:00 P.M., to find out that Bob, who just sent you a critical e-mail, is online and available to chat? We will explore this a little later in this book.

Figure 1.7. Presence Representation in Outlook 2007

We’re almost through with our unified communication primer. The last stop before we dive into OCS 2007 is to take a 50,000-foot view of Microsoft’s history of unified communications, starting with Exchange 2000.

It would be great to be able to say that Microsoft had always planned to be a player in the presence and unified communications spaces. However, that would be revising history just a bit. In truth, to an outsider, it appears as though Microsoft made several failed attempts at getting this type of technology off the ground. Sure, it had MSN Messenger out there for a long time, but on the corporate side, Mr. Gates was not too successful. In fact, there have been rumors that during its lifetime, the entire Communications Server product line had been scrapped, left for dead, but later revived. Although we could discuss earlier Microsoft products, such as NetMeeting, the first real push into the world of IM and presence came with Exchange 2000 Enterprise Edition, which included a feature known as the Instant Messaging Service.

Exchange 2000 and IM

The following paragraphs come directly from the official Exchange 2000 manual:

“Microsoft Exchange 2000 Server Instant Messaging Service offers a fast and simple way for users on a TCP/IP network to communicate instantly. Instant Messaging complements e-mail in a way similar to the way telephone service complements postal mail; however, Instant Messaging also provides information about whether your contacts are present and available at their computers when you send a message.

“Users can set their availability status to any of the following: Online, Invisible, Busy, Be Right Back, Away, On the Phone, Out to Lunch, or Appear Offline. If you have not used your computer during the last 20 minutes, Instant Messaging Service automatically sets your status to Away.”

Sound familiar? If not, flip back a few pages. As you can see, the intent was good, but the technology was not quite there yet. However, this really was the foundation for LCS 2003. At this stage, having “presence” indicators is great, but do I really want to change this every time I go into a meeting? Or if I’m away from the PC for 20 minutes? And what with Y2K, the introduction of Active Directory, and those ugly little Active Directory Connectors, did we really want to worry about rolling out “IM”? And what about the fact that the IM client was the Windows Messenger client, which was outdated the minute it was released (Figure 1.8)?

Figure 1.8. Windows Messenger

In any case, Microsoft made another run at this three years later. This time, however, it decided it was a better move to separate the product from the Exchange bundle.

LCS 2005

LCS 2005 was truly a breakthrough for Microsoft regarding its unified communications and presence initiatives. Finally, it had what could be considered a proper presence solution. Table 1.1 is a breakdown of the feature comparison between LCS 2003 and LCS 2005.

Table 1.1. LCS 2003/2005 Feature Comparison

Feature	LCS 2003	LCS 2005
Secure IM		X
Federation (communication between two LCS installations)		X
Public IM connectivity		X
PBX integration		X
Up to 150 contacts		X
Exchange integration for Busy/Out of Office		X
Application sharing		X
Capacity planning toolkit		X
Microsoft Operations Manager 2005 support
Archiving		X
Clustering (Enterprise Edition)		X
File transfer	X	X
Desktop sharing	X	X
Presence status	X	X
Live Meeting integration	X	X
“Do Not Disturb” setting	X	X
Integration with Microsoft applications	X	X

As you scrolled down Table 1.1, you probably noticed that a significant number of features really made LCS 2005 a “prime-time” application. With the exception of call control, everything that we have discussed up to this point as being a key piece of the “unified communications” world was being wrapped into this package. Let’s talk about some of the more important features of the LCS 2005 product. Figure 1.9 shows LCS 2005 as seen via MOC 2005.

Figure 1.9. LCS 2005 (As Seen via MOC 2005)

Secure IM

Microsoft was wise enough to recognize that communications going across IM needed the same encryption capability that e-mail solutions were already using. We had to be able to secure these IMs so that they were not passing in clear text, internally, to federated (outside third-party LCS implementation) partners, and to remote users working from home. To ensure that these IMs were secure, Microsoft provided for the use of the Transport Layer Security (TLS) protocol. TLS works in a client/server handshake arrangement, whereby the client initiates the communication to the server, and the server selects the strongest cipher and hash function and notifies the client. The client can then check the server’s certificate for authenticity, and then begin communication. This was a major step in solidifying the place of presence in the corporate world. We could guarantee that communication would be secure, protecting confidential company information and also meeting regulatory requirements.

Public IM Connectivity

Honestly, without the ability to talk to the outside world, having an internal IM solution is incomplete. Imagine if your corporate e-mail was only able to send mail internally in today’s world. To address this, Microsoft introduced Public IM Connectivity (PIC). PIC made it possible—for a fee—to communicate with MSN Messenger users, Yahoo! Messenger users, and AOL Instant Messenger users. The fee is fairly low (about $3/user/month, varying on the number of users), but it opens LCS to a whole new world. With the introduction of PIC, we needed a way to monitor and track IMs being sent both internally and externally.

Archiving

As mentioned, we needed a way to track IMs that were being transmitted to internal users, federated users, and public IM users. With the LCS Archiving service, we are able to record and recover IMs as needed.

Exchange Integration

With LCS 2003, we were already inside the Outlook mailbox. However, communication was only one-way. With LCS 2005, we were now able to automatically update our presence status by allowing the MOC client access into our calendar, which would automatically change our status to “In a Meeting” as appropriate, and show our next availability. Likewise, when we set our “Out of Office” message in Outlook, MOC was able to present this message to other MOC contacts when they would look at our status in a Microsoft application or the MOC client itself.

PBX Integration

Here’s the big one. LCS 2005 was now able to tie into certain PBX systems, almost always with the use of a third-party gateway product. Typical functionality included the following:

• Remote call control. The ability to answer and place calls to a desk phone (or software-based telephone)

• Click-to-dial. Simply clicking on user properties in MOC, Outlook, or other presence-aware applications to make a phone call

• Location-based forwarding. As described earlier, the ability to forward a call based on physical location and/or current status

• “In a Call” presence. Ties directly to remote call control; shows your presence as “In a Call” when the desk phone is off the hook

Although this was all very exciting stuff in terms of PBX integration, there were two glaring holes in the solution. The first was internal call control (as opposed to relying on a third-party PBX), and the second was the complete lack of any voice mail solution. The latter was solved with the release of Exchange Server 2007.

Some Independent Advice

Several third-party gateway products are on the market today for integrating LCS 2005 with a PBX system. Some are exclusive to the manufacturer, such as Cisco’s Unified Presence Server (CUPS), which ties LCS to Cisco Unified Call Manager. Some are more PBX-agnostic, such as the popular Genesys Labs product known as GETS. For more information on GETS, visit www.genesyslab.com/products/enterprise_collaboration.asp.

The times, they are a-changing. If you were to draw the evolution of communication in a timeline, you would see that the past decade has experienced the most rapid change in well more than 100 years. As our calendars get packed with more and more requests, and we need to do a better job of not only managing our time, but also indirectly impacting the time of others, we need better ways to streamline communication. The technology is now in place for us to move forward and take up this initiative, but it’s up to us as the end-users to put the technology into action.

With many companies coming in and out of the unified communications world early in the process, Microsoft has slowly been building its arsenal of tools and suites before making its big splash into this world. We, the authors of this book—along with Microsoft—believe that OCS 2007 is now the foundation of this unified communications strategy. In the coming chapters, we will take a very in-depth look at this amazing new product from the folks in Redmond. Enjoy.