The essence of communication is breaking down barriers. The telephone, for instance, breaks distance and time barriers so that people can communicate in real time or near–real time when they are not in the same place. But as communications evolve, there are new barriers to be overcome. New forms of communication emerge, such as e-mail, voice mail, fax machines, and pagers, and people use different devices for each of these. Unified messaging (UM) is designed to overcome these barriers. It breaks down the terminal and media barriers so that people using different technologies, different media, and different terminals can still communicate with anyone, anywhere, at any time. Unified messaging is the integration of several different communications media so that users can retrieve and send voice, fax, and e-mail messages from a single interface, whether that is a wireline phone, a wireless phone, a PC, or an Internet-enabled PC.
This chapter introduces the concept of unified messaging and discusses how the technology, along with Unity, has evolved. The topics covered in this chapter are ones that mostly concern organizations, including who manages unified messaging and why, organizational perceptions, and security issues related to converging voice messages with e-mail. Some attention is given to different ways that a user community might adapt unified messaging, as well as what the implementer and manager of unified messaging should expect. Finally, messaging technologies are covered along with legacy switching technologies and Cisco IP Telephony call-processing systems, such as Cisco CallManager.
The Evolution of Unified Messaging
When the concept of unified messaging first was introduced, it appeared to be a grand idea. However, as the technology was implemented, the original idea behind unified messaging was lost. Some vendors developed products that were so purely unified messaging (meaning that they were totally dependent upon the third-party messaging system they were servicing; without this dependency, it couldn't stand on its own) that their very existence was dependent on the messaging system they were installed to service, including the mailbox store and directory. Cisco Unity was one of these pure UM products. Thus, although Unity realized early success, there was a lot to be desired. Reliability and the capability to sustain voice messaging (VM) when the messaging system was unavailable were serious challenges to the early implementations of the product.
Some of Unity's competitors went to the opposite end of the UM spectrum and came out with what the industry calls integrated messaging solutions instead of unified messaging. With integrated messaging, a client deployed at the end user's desktop unifies the messages from the two disparate systems (e-mail and voice). Many companies thought it made sense to deploy these types of solutions. However, if you add fax to this, you mainly have a confused mix of implementations that can vary as much as the features that a given vendor provides in a product. The problem with integrated messaging highlights the fact that, with the current developments in communication, standards are important. Products that offer interoperability are needed. These products might not be from the same vendor, but they must operate together to form powerful solutions for customers.
One thing is certain: The whole idea of unified messaging stirred the messaging industry. Although many options existed, pure e-mail-only systems left less than suitable solutions for companies of any size. The addition of fax vendor support and other multimedia applications integrated into legacy e-mail systems made any notion of useful, easily implemented standards nearly impossible. For the most part, some of these systems have very strong and capable implementations (Microsoft Exchange, Lotus Domino, and Novell Groupwise, to name a few), but this disparity in implemented standards essentially makes it necessary to write code using the proprietary application programming interfaces (APIs) of these messaging vendors. A good example of this is the way in which IMAP is implemented among these applications. Many similarities exist, but there are enough differences to make it challenging to write one solution for all. Thus, for integrated solutions, useful technologies, such as drag-and-drop, would make you think there is more interoperability than there really is.
For unified messaging, the opposite issue is true. Unified messaging solutions such as Unity use the APIs provided by the messaging vendors in lieu of using proprietary ones (to access mail and directory resources). The challenge of using third-party messaging APIs (such as Microsoft's MAPI or the Lotus Notes API) is that, although it is possible to write very functional and capable unified messaging solutions, these messaging APIs lack real voice-messaging support. Instead of treating Unity like a voice-messaging interface into the messaging environment—in other words, like a voice-messaging client—Unity is relegated to acting just like an e-mail client. Unity must compensate for this by accounting for the differences in behavior between an e-mail client and what a voice-mail client should be when accessing these messaging systems.
If the notion of a voice-mail client actually existed within a given messaging system, it would have a different set of characteristics than a legacy e-mail client. These characteristics include giving unified messaging clients—more basically, voice-messaging clients—higher priority when accessing the system than e-mail or other types of clients. This is because the key to voice messaging is the capability to provide a real-time voice interface (such as the Unity Telephone User Interface, or TUI) into the subscriber's messaging store, or voice mailbox. In addition to higher client type prioritization for voice messaging (which can be considered much like application-level QoS), a voice-mail client has other needs that should be exploited through the TUI interface but supported through the voice-messaging client interface in a given messaging system if they were to exist. These needs include fast retrieval of addresses when addressing messages and fast retrieval of spoken names for message addressing. Without these, subscribers experience slow response times in the TUI.
So, back to the present, it is necessary to provide a typical and (after a few years' maturation) simple definition of unified messaging: Using a single message store for voice, e-mail, and fax messages, a unified messaging solution can provide subscriber access to messages with the TUI or GUI in a consistent fashion.
This means moving voice messaging and all the functionality that subscribers are traditionally accustomed to essentially on top of a legacy e-mail system. Add fax on top of that, and you have a perfect solution. Achievable? Without a doubt. A realistic unified messaging solution certainly is viable and obtainable now.
So what does this mean? In essence, unified messaging is the convergence of voice, video, and data at the application layer, pure and simple. Saying this is probably too "worn" or repeated; nevertheless, the implications of unified messaging simply will not go away just because it sounds like an old idea. From this book's standpoint, this also means that Cisco Unity is a convergence product because it fully bridges the gap between legacy voice messaging and electronic messaging. To narrow or eliminate the gap between legacy voice technologies and data technologies is the whole idea behind Unity as a convergence product.