Unified Messaging: Paving the Road to Pervasive Computing
Articles and Tips: article
Senior Research Consultant
Systems Research Department
01 Apr 1995
Unified messaging - the merging of computers and telephony - is the newest frontier in the progress toward pervasive computing. The common denominator to all definitions of unified messaging is the marriage of email, voice mail, and fax send and retrieval under a single administrative structure and a single end-user graphical interface. Unified messaging promotes the stated mission of Novell for the end of the century - "connecting people with other people, and the information they need, enabling them to act on it anytime, anywhere."
This is the second in a series of AppNotes on computer telephone integration for the NetWare environment.
Previous AppNotes in This Series Feb 95 "Computer Telephone Integration: Call Control vs. Voice Processing"
- Introduction
- Computer Telephone Integration
- Administration
- End User Interface
- Messaging, the Next Generation
- Summary
Introduction
Unified messaging - the merging of computers and telephony - is the newest frontier in the progress toward pervasive computing. The common denominator to all definitions of unified messaging is the marriage of email, voice mail, and fax send and retrieval under a single administrative structure and a single end-user graphical interface. The advantages of unifying these currently disparate technologies are:
Common workstation user interface to voice, fax, and email messages
Speech-oriented telephone interface to email and fax messages
Single-point administration of LAN, email, and voice mail
Simplified user interface for quicker end-user training and greater productivity
Figure 1: Unified Messaging Administration and Interface Architecture.
Unified messaging promotes the stated mission of Novell for the end of the century - "connecting people with other people, and the information they need, enabling them to act on it anytime, anywhere." Extending the messaging interface from the workstation to the telephone will provide easier and more universal access to message data and other computing functions, and will allow workers to more quickly and efficiently act on that data wherever a telephone can be used.
A unified messaging system can be separated into the following components:
Computer Telephony Integration(voice/FAX)
Administration
End User Interface
This AppNote explores some of the issues involved in unifying voice, document, and text messaging through computer telephony integration, with a focus on integrating telephone systems and computers within the NetWare LAN environment.
Computer Telephone Integration
Computer telephony integration is a frontier, and like all frontiers, it was initially lawless. Until recently, there were few standards to guide developers attempting to integrate telephony into their software products. In contrast, text messaging is a relatively mature and standardized technology within the computer industry.
While incompatibilities between different Email systems and platforms remains an issue, the basic requirements of Email systems - to store and forward ASCII text and binary attachments - are relatively straightforward. The problem of incompatible systems can be addressed with gateways and messaging middleware. This provides the near-universal cross-system, cross-platform messaging capability that allows, for example, a user on a VAX system to send Email to an MHS user and vice-versa.
Voice messaging, on the other hand, involves digitized analog voice data, recorded in proprietary formats at different sampling rates and bit-resolutions. Specialized hardware, in the form of voice boards, is required to perform the analog-to-digital conversion that digitizes voice data for storage and then reconverts it to analog signals for later playback. These factors combine to prevent the easy exchange of voice mail message files between different voice mail systems.
An even greater problem is the integration with existing telephone switching devices (PBX, key systems). Until recently, PBXs have been designed to use proprietary command languages that differ across manufacturers and even across models from the same manufacturer. Coupled with this are proprietary methods of transmitting call-control information, from in-band DTMF tones to serial, Ethernet and other out-of-band methods. The result is the situation that exists today: voice mail products designed for use with specific switches.
AMIS Standards
To solve the first problem, the voice mail industry adopted a standard, called AMIS (Audio Messaging Interchange Specification) for exchanging messages between different voice mail systems. There are actually two AMIS standards, one for transferring message files digitally and the other for analog message transfer.
The digital specification is the more robust of the two, providing a combination of features from the X.400 messaging recommendation and features commonly available in voice messaging systems. The digital specification is analogous to Email messaging standards, specifying message addressing and transport mechanisms, such as MHS.
The digital AMIS specification provides formats for messaging functions, such as send and receive, reply, forward, message attributes, delivery and receipt status, message recording format, and so on. It also supports features such as inclusion of a message originator's spoken name, message addressing options such as delivery notification, confidential message, and future delivery. Message transfer functions, encompassing connection establishment, security, bi-directional message flow, and so on, are also included in the specification.
The analog AMIS protocol is simpler and less capable than the digital specification, but it's easier for voice processing developers to implement. In the analog standard, AMIS defines a messaging standard where one voice mail system dials a second voice mail system and then plays back the message to be delivered. An AMIS- compatible message contains a standard header that includes address information such as the dial-in number of the addressee's voice mail system, the addressee's mailbox number, and so on.
To deliver an AMIS message, the sending voice mail system dials the receiving voice mail system, then plays back DTMF codes from the message header that identifies the target mailbox, followed by analog playback of the actual voice mail message itself. In this manner, any two AMIS-compliant voice mail systems can exchange messages. The received message is recorded and stored in the format native to the receiving system and the issue of incompatible message file formats is thus avoided.
Figure 2 shows the sequence of events in an analog AMIS session.
Figure 2: AMIS Analog Message Transfer.
The problem of integrating different telephone switches into a unified messaging scheme is the second major stumbling block to unified messaging. Traditionally, the major players in the voice messaging market produced turn-key products that integrated their own proprietary software, computing hardware, and telephone switching devices. Third-party software developers wrote their software to integrate with one or two specific switches and hardware platforms. Examples are VAX/Northern Telecom Meridian, IBM 390/AT&T Definity, and so on. This limited the market for third-party developers and made the porting of their products from one switch to another difficult.
To solve this problem, AT&T/Novell and Microsoft/Intel have developed competing call-control APIs. These APIs provide a middle layer for interfacing to different switching devices and provide a standard API through which developers can access the call-control capabilities of the switch.
Without going into details, the major differences between the competing Novell/AT&T (TSAPI-Telephony Services API) and Microsoft/Intel (TAPI-Telephony API) are:
Third-party call control- TSAPI allows software to control a connection between two devices; TAPI does not.
Server based architecture- TSAPI is designed for client/server applications, with single-points witch integration occurring on the telephony server. This means that the telephony interface hardware resides on the server and the end user uses the telephone to make and receive calls. TAPI is architected to interface to workstation-level integration hardware.The drivers integrating the workstation must exist on each participating workstation, compounding maintenance tasks and reducing reliability.
An illustration of the communications architecture in a TSAPI installation is shown in Figure 3. Note the absence of direct connection between workstations and telephony hardware.
While TAPI focuses on the desktop, TSAPI turns the PBX itself into another server on the network.
Novell has announced plans to include voice processing (voice mail) functionality into TSAPI, making it easier for developers to create integrated voice and call processing client/server applications.
Every major telephone switch manufacturer has either fielded or announced development of TSAPI drivers for their equipment.
Figure 3: TSAPI Communications Architecture.
For the purpose of unified messaging, an AMIS-compliant stand-alone voice mail product that includes FAX send and receive capability is a requirement. The call-processing engine must be able to:
differentiate FAX from voice communications
resolve addressing issues in order to route the received message or FAX to the appropriate mailbox
provide APIs to allow the services of the call-processing engine to be integrated into a unified messaging interface
comply with one of the major telephony integration APIs to ensure integration with the broadest number of telephone switching devices
An example of such a product on the NetWare platform is the recently introduced CallWare, a telephony server NLM with Windows client interface that supplies a full suite of voice and call processing capabilities in a native NetWare application.
The API included in the product's AppTool suite provides message creation, deletion, addressing and forwarding capabilities to Windows developers looking to incorporate voice and call processing into their products. Products like CallWare that provide voice mail services and APIs to their services will play an integral role in future unified messaging systems by allowing messaging system developers to use a snap-in telephone integration package to generate their unified messaging solution.
Administration
Messaging systems that operate in an X.500 directory services environment, such as NDS, enjoy the advantages that this single-point, extensible directory services scheme offers. The basic NDS schema already contains fields to hold an extension and fax number for the purposes of telephony and fax integration.
The following list shows some of the categories of additions to the NDS schema for the User object that would be required to include voice processing in a unified messaging system:
Notification method parameters
Mailbox services
Message parameters
Forwarding and alternate mailbox numbers
The advantages offered to voice mail administration by NDS are the same as those offered to Email: single point administration, synchronization of distributed directories, simplified user data administration, and so on.
Administration of the telephone network and computing networks has traditionally been performed by different functions within the enterprise. However, with the new integration tools and the drive toward unified messaging, the lines between these two functions are beginning to blur.
In traditional voice mail installations, a voice mail administrator takes care of adding, deleting and setting properties and permissions for voice mail users while the LAN administrator performs essentially the same function for the LAN. Marrying these administrative duties via NDS not only reduces manpower requirements, but gives users a single point of contact for problem resolution. It also consolidates management of a critical enterprise communications function under one administrative function.
Voice mail system installation and integration issues can still be controlled by in-house telephony experts, but day-to-day administrative tasks are placed within the domain of the IS department, where it belongs.
To simplify the arduous task of entering voice mail parameters for new users into the NDS database, templates can be built into the call processing administrative interface. For instance, templates with predefined values for different classes of users can be generated to simplify the task of setting up and maintaining the call processing system. New users can be added by simply applying the correct template and then modifying a the few remaining fields that require unique values (see Figure 4).
Figure 4: Adding New Users with Templates.
End User Interface
Integrating voice mail into a unified messaging interface can and is being done today. However, the specialized nature of call/voice processing systems makes it difficult for companies specializing in Email systems to transition to a completely foreign technology in order to incorporate FAX and voice processing into their messaging products.
As a result, voice messaging vendors are supplying APIs with their products to allow developers of messaging software to include voice mail and FAX send and retrieve features within a single messaging interface. This broadens the market for the telephony vendors while providing the messaging application developer a range of competing products to choose among.
To integrate voice and FAX, the telephony API must, at a minimum, provide functions that lists the contents of a mailbox. This includes information such as originating mailbox, name of sender, time of receipt, length of message (voice mail), and whether the message is new or old, and so on. This information can then be incorporated into a unified message list that displays all of the messages, faxes, Email, and voice mail, received by a user.
In addition, the telephony API must include functions to access the voice mail and FAX functions provided by the telephony application. These include message addressing, message record and playback, and FAX transmission and viewing, and so on.
The API developed by CallWare Technologies, Inc. to support their CallWare NLM is an example of such an API. The CallWare API provides mailbox listing functions that output the name and mailbox number of a voice message or FAX sender, the time and date the message or FAX was received, and a flag indicating whether the message is old (previously played/viewed) or new.
Voice mail messages and Email messages share common addressing attributes, such as future delivery, confidential message, and return-receipt request, as well as distribution list delivery. Voice mail messages can also be forwarded or created in response to a received message. This fact allows developers incorporating telephony messaging to create a single unified addressing interface for all messaging media. The CallWare API includes functions that cover all of these addressing options.
A third category of functions in the CallWare API controls voice mail record and playback operations, as well as FAX viewing. These functions allow the messaging developer to create a user interface consisting of the standard play/record cassette controls for voice messages, and FAX image view controls (load, zoom, print, and so on) for FAX documents.
Messaging, the Next Generation
Advances in digital signal processing and CPU horse-power, along with improvements in optical character recognition (OCR) and text-to-speech conversion, are leading to a merging of email and voice mail. Today, Novell GroupWise allows users to dial into their email system to request an audio read back of their new email via text-to-speech conversion.
As speech recognition software improves, functions such as email dictation and addressing via telephone interface will appear in unified messaging systems. The potential for fax read back using an intermediate OCR step also exists. Added to the forwarding and distribution list capabilities of messaging systems, this will allow a fax to be read back and then forwarded to one or more users all through a single phone call.
Today, call processing systems have notification features that can dial a preprogrammed number when you have voice messages and provide an option for message play-back. In the future, unified messaging systems with text-to-speech conversion will dial your preprogrammed notification number, read back email, and provide options for forwarding messages via telephone keypad addressing, and options for creating voice mail replies to the sender.
Interactive voice response - the ability to provide branching logic and/or database queries to voice processing systems - is beginning to be seen today and will be more common in the future. Advanced email processing systems, such as Beyond Mail, include email application programming languages that already provide this functionality for email.
In the future, extensions to encompass voice processing will be included in unified messaging systems programming languages, extending the usefulness that messaging solution providers are currently deriving from programmable Email systems. For instance, where today Email applications are programmed to except data entry in forms that are then merged into databases or spreadsheets, tomorrow, user input will be as easily accomplished by phone.
Applications that automatically generate Email based on an event or a date will be able to generate a voice message instead, so that the management reports sent as Email today will be accessed from home by a simple telephone call tomorrow.
Unified messaging will also make possible applications dear to a system administrator's heart. SNMP agents can be authored to generate phone messages incorporating system status messages, and audio text menu systems, or even command-line schemes can be authored in the voice processing system to make the telephone keypad a remote keyboard for the system console. With telephony integration, the ability to communicate and control computing systems from the telephone handset will be nearly boundless.
Summary
The future of unified messaging will depend heavily upon telephony messaging vendors providing open systems, via APIs, that allow easy integration of FAX and voice messaging into Email applications.
Telephony applications that use NDS will enjoy a distinct advantage over their competition based upon the reduced administrative overhead (user database synchronization, adding new users, and so on) that NDS offers. User interfaces, designed from the ground up to incorporate voice and FAX messaging, will present end users with a single, unified interface to message list, address book, and message send options for all messaging media.
Today, companies can create tightly-integrated unified messaging solutions using the call-processing capabilities of the CallWare engine and CWAPI. Products like CallWare make integrating call-processing services a simple matter of programming to an API and creating a user interface for record and playback functions. With this kind of easy integration in the offing, the availability of unified messaging solutions is sure to take a quantum leap in the very near future.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.