Finding Unified Architectural Diversity A downside to this architecture is the added demand on the voicemail server. Additional memory, hard disk storage and a more powerful processor may be required. Because voicemail servers are usually proprietary hardware, upgrading the system can be expensive. Octel's Unified Messenger and Digital Sound's InfoMail Express deposit messages into a Microsoft Exchange store. This architecture can best be described as an e-mail-centric approach (see "E-Mail-Centric Messaging" at bottom right). The voicemail server has no permanent storage for messages, and messages are received directly from the Exchange store using a phone or PC. The products use a streaming feature built into MAPI to accomplish voice playback and deposit. Since there is only one copy of the message, synchronization is unnecessary. Replies are easily created with the original message attached because of the single-store mode. Depending on the implementation, a u ser may experience some latency while using the phone interface for a variety of reasons, including latency in translating data from its native forma t to the user's requested format, network contention and busy conditions. Octel overcomes this issue by caching the message content on the voice server as the user listens. The next two architectural types (see "Client Integration Messaging" and "Server Integration Messaging" on page 126) use multiple stores for messages. These best leverage embedded systems. For companies that have invested millions of dollars in equipment, software and user training, these architectures can make the most sense. The key to a successful implementation is the seamless integration of message stores at the users' level. With client-integrated messaging, there is no interaction between the store servers, since the integration is done at the client level. A PC client logs into both systems and and i s presented with a combined interface of both stores' contents. A major concern about this architectural style is the reply function. Can the user easily attach the original message to the reply? Can he or she use a phone to forward an e-mail message to his or her supervisor's voicemail? Where will the combined message be stored? The underlying architectural assumption requires both stores support storing any data type. Applied voice successfully implements seamless integration of the message stores so that the user experiences only a single store. Server integration messaging architecture uses multiple stores for messages, but it synchronizes between these stores. Lucent's solution offers user-configurable options for flexible customizability. One user may choose to have messages stored in the voicemail store. Another may have them stored in the e-mail store. A third may have only e-mail message headers sent to the voicemail store, while a fourth may decide to have no unification. Because synchroniz ation is performed at the server, latency is not an issue for messages stored in the voicemail server. If several users store their messages in the voicemail server, the server's capaci ty must be evaluated so that the proper memory and disk space is available. But you will gain easy administration, backup and maintenance. The fourth architecture introduces additional work for the administrator--managing the synchronizer, monitoring its performance and ensuring that it is running. If the synchronizer stops running, the synchronization of mailboxes ceases. However, if you have a large investment in machines, products and user training that you wish to leverage, this architecture might be for you. Of the two architectures that support legacy systems, we prefer the synchronizer (server integrated), even with the added administrative costs. Because of better integration of media types, the requirements on client machines (for memory, disk space, processing capacity and administration) is diminished. Other Considerations Before you begin to deploy a unified messaging system, consider some of the pitfalls and technical issues involved. This will help you minimize their impact on your system implementation. For example, users might experience greater-than-normal latency when accessing messages with a non-native device, such as when checking e-mail from a telephone. Such a delay might be caused by the load on the voice server, the network, the message server or the text-to-speech processor. You must decide where messages will be stored. By keeping copies of messages in two stores--a voice server and a mail server, for example--you let users retrieve messages using a phone or a PC, but you then double the amount of disk storage needed. Lucent's solution gives three options: messages are kept in both stores, only messages headers are kept in the non-native store, or no duplication of message information is allowed.

QoS: Crating Inequality in an Equal World by Chris Lewis Updated May 12, 1997