Email used to be fairly straightforward. When implementing email technology, your major challenge was to ensure interoperability between different email systems. But once you achieved that interoperability, you could sit back, content in the knowledge that users could send messages to each other without hindrance.
Email is different today. More means of communications exist, more points of access are available, and more content types exist. If we used a separate device for each type of communication, our systems would resemble warriors with devices slung from every available patch of combat webbing. If this vision seems ridiculous, think of how many devices you take on a business trip: cell phone, pager, notebook PC, and perhaps a palmtop for quick access to notes and phone numbers. Wouldn't you like to have one seamless system that had multiple points of access through a range of different devices?
Unified messaging is a hot topic today. Maybe it's the answer that will help us make more sense of information overload. When senior Microsoft executives discuss their plans for Platinum—Exchange Server's next major functionality release, due in 2000—and for the Windows 2000 (Win2K) platform in general, they talk about unified messaging. This article discusses Exchange Server 5.5's current state of voicemail integration and looks at how messaging will evolve when Platinum and Win2K hit the streets.
What Is Unified Messaging?
Unified messaging is a much-abused term, so I want to define it in practical terms. Unified messaging provides anytime, anywhere message access—via telephone or other communications devices—to one location (the Inbox), which can contain email messages (and the variety of attachments they transport), voice messages, faxes, Short Message Service (SMS) messages, pager messages, and so on. To some degree, you can unify communications around your Inbox today, but the range of devices that can currently access and interact with your Exchange server's Inbox is limited. Microsoft's goal is to expand the range of useful devices in Platinum.
Exchange Server's original vision was information exchange, and Microsoft designed the server from the start as a platform for messages containing both voice and data. However, the majority of information that Exchange servers process today remains text-based, although fax integration through connectors is fairly common. Connectors have extended Exchange Server's reach in terms of the number of systems the messaging system can communicate with, but users haven't really moved beyond viewing Exchange Server as simply an email server.
Unified messaging solutions extend a standard email server to support different types of communication. Voicemail integration is the most popular and available unified messaging solution today. Figure 1 illustrates a typical unified messaging solution. Software layered onto a PBX captures voice messages and translates them into a format that the email server can understand. In an Exchange Server environment, the Telephony API (TAPI) is the software layer between the PBX and Windows NT. The Messaging API (MAPI) translates voice messages for Exchange Server, which delivers the translated messages to users' Inboxes. Users can then play the messages over a desktop PC's built-in speakers. However, you need to use a client that can understand the voicemail format. Microsoft Outlook and the original Exchange client—which only Exchange Server 4.0 and 5.0 provided—can play messages if you've installed a custom form, but POP3 and Internet Message Access Protocol 4 (IMAP4) clients such as Outlook Express can't. Nor can you use the Outlook Web Access (OWA) browser connection. You can, however, extract voicemail attachments and play them as you would play standard voice files.
Still a Rarity
In the right environment, the current generation of voicemail products works well and delivers some of the vision of unified messaging by integrating voice and fax with email. But unified messaging is still a rarity in Exchange Server installations. The following are some reasons why Exchange Server hasn't moved forward toward Microsoft's original vision:
- the perceived cost of extending Exchange Server in terms of software licenses (for the unified messaging software) and additional hardware
- the relative lack of API access to the Exchange Server 5.5 messaging engine
- the relative immaturity of the unified messaging space
On the surface, extending Exchange Server with any third-party product incurs license fees and probably increases hardware demand to the point at which the hardware requires some kind of upgrade (e.g., CPU, memory, hard disk). Software vendors need to generate a return on their investment. And even though the Exchange Server marketplace has reached more than 25 million seats (at the end of second quarter 1999), add-on sales for unified messaging haven't reached a volume comparable to that of more popular extensions such as virus checkers, fax connectors, management tools, and backup products.
Some companies, including Microsoft and several independent consulting firms, maintain that a unified messaging solution's cost is cheaper than the cost of deploying voicemail and email on separate platforms. I suspect that these companies' requirements and infrastructures vary so much that such a sweeping generalization—unified messaging will be cheaper for you—is impossible. Understandably, Microsoft advocates unified messaging built around Exchange Server, as outlined in a white paper available at http://www.microsoft.com/exchange/km/um.htm.
The relative lack of APIs for Exchange Server increases development costs and eventually increases license fee costs. MAPI is a comprehensive API, but it has limited access to the Information Store's (IS's) contents. Applications must mimic a mailbox to interact with the IS, or vendors need to write clientside extensions to process new types of data, such as voicemail messages. Direct access to other Exchange Server components such as the Message Transfer Agent (MTA) and connectors doesn't exist, so applications need to channel everything through the IS route.
Microsoft extended Exchange Server 5.5's Directory Store by adding a set of voicemail attributes that make the Directory Store more attractive to integrators. The attributes, which the Directory Store holds on a per-mailbox basis, include voicemail greeting, voicemail password, voicemail recorded name, voicemail user ID, and so on. Exchange Server doesn't inherently use these attributes, so developers can decide what to do with them. You don't have a client user interface (UI) to view the voicemail attributes, so you need to run the Exchange administration program in raw mode to see them, which Screen 1 shows. You can't currently customize the Directory Store to meet specific application requirements, so out-of-the-box attributes are a welcome development. Otherwise, developers would have to store this data in another custom directory. Win2K's Active Directory (AD) offers a totally extensible schema, so developers will have the freedom (within reason) to add their own voicemail attributes to the directory.
Advances in hardware capabilities have had much influence in this arena. Faster desktop clients can process voicemail messages more smoothly, and faster servers equipped with multiple CPUs and better disk subsystems can store and provide large voicemail attachments more smoothly to clients.
What's Available Today?
Two types of voicemail integrations are available for Exchange Server deployments today: server-centric and client-centric. A server-centric integration delivers voicemail to Exchange Server Inboxes the same way it delivers email. Architecturally, bringing everything together on a common server presents the most seamless and attractive solution. Microsoft emphasizes the server-centric approach in Exchange Server, which can process multiple message types. Future enhancements to the Exchange Server platform will make this type of unified messaging far easier to engineer.
Lucent Technologies' Unified Messenger (http://www.octel.com/um) is well integrated with Exchange Server. Unified Messenger, which you manage through the Exchange administrator program, uses the IS to hold its voicemail and fax messages and lets you address new voice messages via the Global Address List (GAL). Lucent demonstrates impressively what you can do today to exploit Exchange Server as a unified messaging platform. If you're looking for an integrated solution, Unified Messenger deserves serious consideration.
Unified Messenger delivers voicemail—along with email—directly to a user's Inbox. The user can listen to messages over a telephone or the PC's built-in speakers. Unified Messenger supports both the original Exchange client and all versions of Outlook. It also provides additional menu options and icons for the client interface so that users can create new voice messages and reply to or forward existing messages. Screen 2 shows the Unified Messenger options as they appear in Outlook 98. The Inbox contains voice and email messages. (A small telephone icon is attached to the voice messages.) Additionally, Unified Messenger lets you retrieve both voicemail and email from a telephone; its text-to-voice software (which can translate English, French, and German) can read a message's title, sender, and content.
The client-centric approach doesn't use Exchange Server. Instead, MAPI or IMAP4 function calls process voicemail messages, which reside in a separate repository. Nortel Networks' CallPilot (http://www1.nortelnetworks.com/ entprods/messaging/callpilot) is a good example of a product that uses client integration for voicemail. CallPilot is an evolution of Nortel Networks' successful but proprietary Symposium Messenger, which now runs on NT with interfaces for MAPI, IMAP4, and Lotus Notes. Desktop clients for CallPilot include Outlook, Outlook Express, Netscape Communicator, Lotus Notes, and QUALCOMM's Eudora.
CallPilot doesn't use Exchange Server's IS to hold messages. Clients query the CallPilot repository to fetch and play messages, but the client UIs make the join reasonably invisible. The software stores messages in a database on a system running NT 4.0 Service Pack 5 (SP5). Nortel's PBX is Meridian, the most popular PBX in the United States. The CallPilot server for Meridian comes on a card that you insert into the PBX just like you'd insert a network card into a computer. The server includes a 166MHz Pentium processor, 128MB of RAM, a 4GB hard disk, and two Ethernet cards to connect to the PBX and the LAN. The hard disk has enough space for NT, the application, and storage for 200 voicemail messages. You can purchase upgrades if you need to store additional voicemail. CallPilot also supports PBXs from other manufacturers (e.g., Lucent, Mitel).
Screen 3 shows Outlook 98 accessing CallPilot messages, which reside in a separate store, which resembles an Exchange Server mailbox or Public Folders. The separate store is a major technical difference between server-centric and client-centric voicemail integrations. You map the separate store through the CallPilot MAPI Information Service, a set of one or more DLLs that contain the necessary functions to let MAPI clients navigate through the CallPilot store. Clients use Lightweight Directory Access Protocol (LDAP) to access the CallPilot address book, which isn't part of the GAL because different clients share it. You can download and access voicemail messages offline in the same way that you download and access email. The CallPilot Player for Outlook, which Screen 4 shows, reads text, voice, and faxes. However, Web browsers don't need a separate reader because CallPilot supports Microsoft's WAV format (which the Microsoft Media Viewer can play back) and Nortel's voice block (VBK) format. VBK is much more compressed than WAV and is ideal for playing messages over the telephone.
The proponents of each approach make strong arguments for implementation. Administrators who use server-centric Exchange Server point to the fact that they deliver a well-integrated solution; those who use a client-centric solution maintain that they do the best job of covering all available desktops. Supporters of a client-centric solution also say that a totally integrated solution is great until the Exchange server is down, at which point users lose access to both email and voicemail. Operating the two services independently might deliver more resilience, but that argument is valid only if you expect Exchange Server to go down regularly, which shouldn't happen in any production environment.
Platinum's Voicemail Platform
Two of Platinum's most important goals are to create a more extensible platform and to enable access to a wider variety of clients. Microsoft has completely overhauled Platinum's IS. The most important change is the provision of a streamed database to store information that clients don't typically access in a structured manner.
Microsoft organized Exchange Server 5.5's IS for hierarchical access via a mailbox and then down to folders and individual objects. The IS stores data in tables and rows similar to those of a classical relational database. At the lowest level, the IS arranges data in 4KB pages. Data in 4KB chunks is appropriate when you want to retrieve information, such as a message's recipients, which typically fits on one page. Most messages' body or content fits on one page, so the IS can service client requests efficiently. However, attachments—particularly large files—pose a challenge for a database built on 4KB pages because the system doesn't necessarily store data contiguously. Fetching a large attachment can force the IS to inefficiently retrieve many pages from different parts of the database. Even with the latest encoding algorithms, voicemail messages are usually large (e.g., 100KB or more), so integrated voicemail clearly requires much power to drive today's IS.
Platinum's streamed database supplements the IS's EDB databases by taking responsibility for the storage of native Internet data such as MIME-encoded messages that Internet clients (chiefly Web browsers and IMAP4 clients) generate. Unlike the EDB databases, the streamed database stores information in contiguous chunks. Fetching an attachment is therefore a matter of requesting a continuous stream from the start to end of a file. For example, fast-forwarding to a specific part of a voicemail message is feasible. Exchange Server still places indexed data, such as MAPI properties (e.g., subject, date sent, message recipients), into the EDB databases. Additionally, MAPI clients such as Outlook 2000 won't use the streamed database at all. This direction suggests that voicemail clients will probably use IMAP4—or other Internet protocols such as HTTP-DAV—instead of MAPI in the future.
Microsoft is assembling an impressive lineup of third parties that are committed to exploiting Platinum's new features and using the messaging system as a unified messaging platform. Aside from Platinum's powerful programming and storage capabilities, the ability to use Win2K's AD as one definitive directory for the many types of data now scattered across multiple databases is obviously attractive. AD has a customizable and extensible schema, so vendors can add fields to hold information such as access numbers. After you add your first Platinum server to a Win2K domain, these fields will build on the extension that Platinum makes to the AD schema.
Vendors that support Exchange Server today, such as Lucent, are among many companies announcing their support of Platinum, but vendors that haven't supported Exchange Server in the past are also supporting Platinum. Nortel Networks has announced that the next-version CallPilot will move from the company's current client-centric approach and integrate voice and fax applications using Exchange Server as its store. Intersis Technologies' Voice for Microsoft Exchange (VoiXX—http://www.us.voixx.com/ prod_arch.html) and Active Voice's Unity (http://www.activevoice.com) will also support Platinum. Today, VoiXX and Unity run with Exchange Server 5.5, but the vendors hope that Platinum will be much more scalable and capable of handling more simultaneous voicemail connections. For example, Unity 2.0 is capable of supporting 120 circuit switch ports—a limit that should be exceeded thanks to the changes Microsoft is implementing in Platinum.
Voice-Enabled Client Expansion
Although MAPI remains an important client protocol—indeed, the protocol that Microsoft still favors in Outlook 2000, its most functional client—Internet client access protocols such as LDAP, IMAP4, and Voice Profile for Internet Mail (VPIM) are the subjects of increasing focus.
These protocols can allow access from the widest possible range of clients, including Outlook and Internet clients such as browsers and IMAP4. Windows CE devices are gaining popularity, but Windows CE doesn't support MAPI, and Pocket Outlook supports only POP3 access. Third-party vendors have stepped into Microsoft's gap to add IMAP4 support for Windows CE devices. The best known of these products is probably Ruksun Software Technologies' IMAP Force (http://www.ruksun.com/windowsce/index.html). You can expect Microsoft eventually to update Pocket Outlook to use IMAP4. The most interesting advance will involve telephone access, particularly for cell phones. If unified messaging's aim is to establish a common repository for all types of messages, facilitating access from the most ubiquitous access device—the telephone—is mandatory.
VPIM is the MIME voicemail format as defined in Request for Comments (RFC) 2421 (ftp://ftp.isi.edu/in-notes/rfc2421.txt). VPIM2 is the current version, but VPIM3 is forthcoming. The major difference between these two versions is that VPIM2 concentrates on server processing, whereas VPIM3 specifies how desktop clients handle voicemail. Microsoft plans to support VPIM2 and VPIM3 in Platinum through a gateway and build future voicemail processing around this standard. You can find further information about VPIM at http://www.ema.org/vpimdir/press.htm.
Microsoft has already suggested its intention in the unified messaging arena through WirelessKnowledge (http://www.wirelessknowledge.com), the company's joint venture with QUALCOMM. WirelessKnowledge is dedicated to enlarging the Exchange Server platform by expanding the messaging server's set of available clients to include wireless devices, digital phones, and devices equipped with microbrowsers (e.g., the Nokia 9000 series, public Web kiosks, Microsoft's WebTV). As further proof of Microsoft's interest, a cellular phone station sits atop the Exchange Server engineering group's building on the Redmond campus. Development is in a late stage, and Microsoft has demonstrated access to Exchange Server using Cellular Digital Packet Data (CDPD) and Code Division Multiple Access (CDMA) cell phones. (For more information about CDMA, see http://www.qualcomm.com/ cdma/phones/whatiscdma.)
Microsoft hopes that Platinum—by combining base features and interfaces with a collection of third-party integrations—will make Exchange Server a server that you can dial up to access all your messages. With products such as Lucent's Unified Messenger, phone access is available to Exchange Server mailboxes today, but functionality is limited to basic features such as read, delete, and forward (i.e., using the numeric keypad to drive commands). Cell phones are now typically equipped with small LCD panels that you can use to browse Inboxes (or other folders) and respond to messages. Initially, Platinum will probably limit messages to a set of preprogrammed responses in the form of simple phrases such as Yes, No, and I'll attend the meeting. Users will also be able to perform simple message manipulation, such as forwarding and deleting messages. The small LCD panels obviously limit the capability of a cell phone to process large Inboxes. Platinum might restrict forwarding, like the responses, to a predetermined list of favorites because the ability to browse a GAL is unlikely. But given the rate of development in cell phone technology and the capabilities of some high-end devices from companies such as Nokia, the availability of a much-enhanced feature set is entirely conceivable in the near future. I'm not sure I'll want to use my phone to process the volume of messages I receive daily, but the ability to access important messages at the press of a button will certainly be valuable.
The importance of integrating telephone access with email differs internationally. Cell phone ownership in Scandinavian countries such as Finland, Norway, and Sweden is far higher than that of Southern Europe. In the United States, cell phones are popular, but pagers are even more omnipresent. In Europe or Asia, however, pagers are less popular than cell phones are. Integrating email, voice, fax, and pagers around Exchange Server can leverage the rapidly growing Exchange Server user base and the huge number of cell phone owners. But how many Exchange Server users with cell phones really want to use their phone to access email? The jury's still out.
Into the Future
Microsoft quotes a study by the Radicati Group, a market-research firm in Palo Alto, California, that estimates that companies can gain 30 minutes a day in productivity from knowledge workers using Exchange Server's unified messaging features. The study also estimated savings of 70 percent in administrative support costs from using these features. I'm somewhat baffled by these findings. Certainly, bringing systems together to share components such as directories and storage repositories eliminates redundancy and reduces costs, but we have yet to see a 70 percent savings.
We can assess unified messaging's true worth, like the worth of all technological advances, only when the technology becomes more than an interesting experiment in computer science and enters the mainstream of daily business life. Win2K and Platinum certainly provide the platform for telephony vendors. Seeing just how many companies exploit these new capabilities and invest in unified messaging over the next couple of years will be interesting.
Corrections to this Article:- "Unified Messaging" incorrectly states that Nortel Networks' CallPilot server for the Meridian PBX can store as many as 200 voicemail messages. The CallPilot unit that the article references can store as much as 200 hours of voicemail messages. Also, the correct meaning of the acronym SMS in the article is Short Message Service. We apologize for any inconvenience these errors might have caused.
