Three years ago, it would have been hard to convince people that Internet protocolswere the best way to move voice mail and fax messages. Three years from now, it may behard to imagine a better way. The vehicle responsible for this potential transformation isVoice Profile for Internet Mail (VPIM), which defines an Internet standard for exchangingvoice mail and voice-mail-based fax messages between mail servers.

While both public and private standards exist for voice, fax and email systems,Internet-based mail standards--Simple Mail Transfer Protocol (SMTP) and MultipurposeInternet Mail Extensions (MIME)--have tremendous momentum and are becoming the commondenominator. However, simply moving to an Internet standard is not enough. The ubiquity ofthe telephone and the widespread use of voice mail systems has to be taken into account --people are not about to stop using them. Therefore, VPIM specifies how messages areexchanged between mail servers--not the way these servers interact with clientapplications or the way they interface with the end user. This allows many different kindsof existing systems to support VPIM and also allows for future support by advanced desktopclients.

With VPIM, users of traditional voice mail systems can continue to access and operatetheir systems via the telephone, while users of the latest multimedia messaging systemsuse graphical PC screens and mouse clicks. VPIM simply lets these systems exchangemessages across TCP/IP-based intranets and the Internet. Because VPIM currently focuses onserver to server message exchange desktops will require VPIM helper applications tocorrectly record and playback applications. A subsequent revision to VPIM that addressesthe specific needs transparent desktop multi-media message exchange is currently in theworks.

VPIM resolves long-standing difficulties in simply transporting messages between disparate voice mail systems, and enables inexpensive transport via TCP/IP intranets andInternets. It also facilitates intentional messaging: the creation and sending of voice messages without any real-time involvement with the recipient (or his/her voice mailsystem or answering machine). Sending an intentional message means not having to call thedistant party, see if someone answers, ask for the person you want, find out they are notin, then listen to that party's voice mail greeting before leaving a message.

This relatively new use of voice messaging differs from voice mail's original application--replacing secretaries and handwritten message slips. Intentional messaging didn't take hold until users became familiar with and learned to trust voice messaging'sforwarding, reply and distribution list functions. Then frequent travelers began using it to handle multiple messages on a single call and reduce calling expense. Today it is inwidespread use among people who interact regularly. Short, directed, intentional voicemessages have become the predominant way that workgroups accomplish their daily tasks inmany corporate environments.

Who's Backing VPIM?

The VPIM specification is basically a MIME profile, that enables voice mail servers to encode and exchange messages via SMTP with any other SMTP/MIME-capable server, over TCP/IPnetworks (see sidebar: What is VPIM?). VPIM is widely supported by all the industryplayers, including virtually all voice mail system vendors and voice messaging serviceproviders. Trials, demonstrations and product announcements are in full swing since theElectronic Mail Association (EMA) Conference in Philadelphia last Spring.

At the EMA show, vendors connected their systems into a network that also includednodes in California and Canada. The demo showed VPIM-based messaging capabilitiesincluding forwarding, reply, distribution lists and faxing, and also included the use ofshared X.500 directories and the Lightweight Directory Access Protocol (LDAP) standard.

Both VPIM gateways and native-VPIM messaging systems are entering the market this year(see Tables 1 and 2). Service providers are also backing VPIM. Members of The MessagingAlliance (TMA)--whose voice mail network includes Bell Atlantic/NYNEX as well as otherservice providers -- plan to support VPIM gateways in their services. Directory andbackbone service providers, such as IBM’s Telecommunications and Media IndustrySolutions Unit intend to offer enterprise and inter-enterprise VPIM directory and messagetransport services. Other major voice message service providers also plan to use VPIMgateways and systems to offer new messaging services that will enable many kinds ofinterface devices--including phones, PCs, cell phones, fax machines and pagers--toexchange messages with one another and with public or corporate messaging clients.

The VPIM World in Microcosm

While the deployment of VPIM is likely to be gradual, its long-term effects will beprofound. Because the specification defines only how mail servers interact with eachother, not how they interact with client applications or with end-users, VPIM does notimpose changes on work practices and social patterns. In turn, end users will find thatVPIM extends the functionality and the reach of voice mail and enhances message exchange.

Companies will first use VPIM gateways to tie existing internal voice mail systemstogether, then perhaps to link them more tightly with remote sites, mobile workers andtrading partners. In the lower left of Figure 1, we can see how existing voice mailsystems and networks will connect to TCP/IP intranets or to the Internet via VPIM gatewayson SMTP hosts. These gateways consist of software modules or adjunct standalone systems.

Also shown in Figure 1 are new voice messaging systems. Some will include native VPIMand SMTP routing of VPIM messages, and will support directory address look-up. Thisdirectory may be proprietary (e.g., Banyan, Microsoft or Novell), with support for LDAPaccess, or it may be an open, X.500-based directory. A standalone VPIM gateway and adirectory server are shown, although combined gateway/directory servers will be especiallyuseful with existing, proprietary voice mail servers and networks.

Email and other client-server applications can support VPIM's MIME constructs in thesame way they currently support other MIME parts. Lacking a telephone interface, thesesystems are likely to need "helper" applications for their GUI client softwareon the user's PC to play and/or record VPIM messages through the PC's local speaker andmicrophone.

Tables 1 and 2 summarize the status of VPIM support on messaging servers and gateways.Note that Centigram (San Jose, CA), Nortel (Richardson, TX), Siemens BusinessCommunications (Santa Clara, CA and Lucent’s Octel Messaging Divison (Milpitas, CA),)all plan to use VPIM gateways with their current voice message systems and networks, whilenew releases from these and other vendors will feature native VPIM and be able to connectdirectly into a corporation's TCP/IP and SMTP network. In addition, vendors includingLucent and the Siemens/Active Voice Corp. partnership are planning unified messagingservers that rely on email message stores (in both these cases, Microsoft Exchange). Thesesystems, as well as others that use Internet SMTP stores or that support IMAP4 and POP3,are also likely to implement VPIM, but will need the helper apps described above to enablePC clients to record and play VPIM messages.

Where Do Directories Fit?

Voice mail systems use the address formats of either the InternationalTelecommunication Union (E.164) or the North American Numbering Plan (NANP: 123-555-1212),along with internal corporation-specific numbering plans that may include a site numberand voice mailbox number or extension (e.g., 23-4455). Sophisticated voice messaging usersmay know how to dial their colleagues' voice mail box directly; others dial the calledparty and wait for a certain number of rings (or a human) to "put them in" voicemail.

In contrast, email addresses (typically in the Internet format: giselle@mycompany.com)are routinely entered by the sender when he/she creates an email message. Some usersmaintained PC-based personal directories of their frequent email correspondents.

To achieve the VPIM vision of open messaging, voice message systems must be able tofind and apply Internet-routable addresses based on telephone numbers. Thus shareddirectories are much more important in open voice messaging than they are in email.

There are three levels of directory information in voice mail environments:

* Corporate directory or corporate white pages directory

* Shared public or inter-enterprise directory

Information on the voice mail system directory level is application-specific and oftencontains system-related information optimized for performance. Other kinds of informationare often stored on both the voice mail directory and the corporate white pages directorylevel (such as user names and phone numbers).

At the top level, trading partners with connected messaging networks--or voice messageservice providers--need to share access to their voice mail directories. Sharing thisinformation doesn't necessarily mean centralizing the data. For example, the directoriescan simply share a schema (a la X.500) that enables them to know which server containswhich information and to route requests for information to the appropriate directory.

The best solution for voice mail lies in open and shared directory services at allthree levels, an effort that goes beyond the scope of the VPIM profile. But because of theimportance of these shared directories to VPIM's success, VPIM participants have examinedhow their systems can fit into an overall design that includes all three directory levels.

LDAP is a good place to start for voice-mail directories that need to communicate withcorporate white page directories. LDAP is a widely accepted, open standard that allowsclient applications to access directory information. It is supported by virtually alldirectory vendors and is also consistent with its more-comprehensive parent, the X.500directory model.

With LDAP, application servers, such as voice mail systems, can read or update acorporate white pages directory database. For instance, after creating a voice mailmessage by phone or forwarding a message to another recipient, the user must address themessage by entering the recipient's phone number. The voice mail server then makes an LDAP"read request" over the network to a corporate white pages directory, asking forspecific attribute information associated with that phone number. The directory servermight then return the spoken name and the VPIM-enabled mailbox address where the messageshould be sent. The user hears and confirms the spoken name, thereby validating theaddress, and the voice mail server then sends the message.

Continuing this example to the top level of shared inter-enterprise directories, if therecipient's phone number were not within the corporate white pages directory, that systemcould make a request to a shared public directory or to the shared portion of a tradingpartner's corporate directory. X.500 directories are most beneficial at this top level.Their open protocol allows many different organizations to share selected information,while the advanced capabilities of the X.500 protocol permit control and management of theshared directories.

Service providers, including the RBOCs, are currently trialing shared X.500 directoriesthat provide access into their entire voice mail subscriber bases. Coupled with VPIM, thisdirectory sharing would let a message be created and retrieved using the telephone, buttransmitted using the Internet, which could prove much less expensive than a phone call.Callers may also prefer (and be willing to pay for) the convenience of creating andsending a message without having to dial the distant party, listen to their voicemailgreeting and then leave a message.

As shown in Figure 1, directory services can be provided within voice message systemsas part of a VPIM-enabled voice mail system or gateway, or on a standalone server. Thestandalone directory at the bottom of the figure could serve at all three directorylevels--application, corporate or inter-enterprise. Using X.500 and other directoryadministration tools would enable replication between directories and references to otherdirectories as needed. While proprietary directory servers (e.g., from Banyan, Microsoftand Novell) can perform the replication and referral functions in closed networks, an openstandard like X.500 (e.g. IBM) makes more sense in a public or shared environment.

If the end user's voice mail server directory is compatible with a corporate and ashared public or inter-enterprise scheme, he or she can take advantage of other advancedservices. These include personal directory information stores, where the voice mail systemcan find numbers and addresses that aren't public (but are included in a personal addressbook), and distribution lists that span voice, fax and email systems.

Conclusion

While not yet complete, the picture of how VPIM and open directory services increasethe utility of messaging is clear enough to trigger the early stages of planning.Corporate planners can start with an inventory of their existing message systems andgateways to find out which departments and workgroups are now using or could benefit fromintentional voice messaging. Analyzing call detail reports would identify frequent, shortcalls between buildings and departments, and between sites in different time-zones.

VPIM can be added incrementally, to connect specific voice mail systems as needed.Effects on the TCP/IP network backbone can be managed by quantifying message traffic,bearing in mind that each minute of MIME-encoded voice messages will require 320 Kbytes(via SMTP, or 240 Kbytes with the more efficient binary SMTP service extensions). Becausemessaging traffic is stored and forwarded, it can be sent at off-peak intervals andprevented (by router parameters) from interfering with higher-priority, or real-timetraffic. Because VPIM traffic is server-to-server, it need not impact the end-users' LANs.As experience is gained, traffic assumptions can be validated and VPIM can be deployed ona broader basis.

Directories present challenges to the organization that include, but go well beyond,voice messaging. VPIM deployment will benefit from, but does not depend upon, open shareddirectories at all three of the levels described above.

As shown in Tables 1 and 2, VPIM-capable gateways and servers will soon be available toimprove existing message server connections and facilitate enhanced messagingapplications. RFPs for voice message systems should insist on VPIM and LDAP support thatincludes spoken name for all directory entries. RFPs for open corporate directories shouldask for integration down to the application level of voice mail and up to the shared,inter-enterprise level, and they should also include spoken names and distribution lists.

Adapted for republication with permission of publisher, Business Communications Review, from Volume 27, Number 5 (May 1997), pp 43-47. BCR Enterprises, 950 York Road, Hinsdale, IL 60521 (USA).

Back to top