VPIM

TABLE OF CONTENTS

1	Introduction…………………………………………………………………...3
2	The VPIM Initiative…………………………………………………………..3
3	Analog Networking…………………………………………………………...4
4	Voice Messaging System Limitations………………………………………..5
5	Design Goals…………………………………………………………………..6
6	VPIM’s Features over AMIS Networking…………………………………..7
7	How VPIM works……………………………………………………………..9
7.1 Architecture…………………………………………………………….…..9
7.2	VPIM Addressing……………………………………………………….….9
7.3	Voice Message Content Types………………………………………….….11
8	VPIM Conformance Requirements………………………………………….12
9	Security Considerations………………………………………………………13
10	Protocol Restrictions………………………………………………………….14
11	Example Product…..…………………………………………………………..15
12	Example Scenario of VPIM’s Usage………………………………………….15
13	Summary……………………………………………………………………….17

   

1 INTRODUCTION: 

	A class of special-purpose computers has evolved to provide voice messaging services.  These machines generally interface to a telephone switch and provide call answering and voice messaging services.  Traditionally, messages sent to a non-local machine are transported using analog networking protocols based on DTMF signaling and analog voice playback.  As the demand for networking increases, there is a need for a standard high-quality digital protocol to   connect these machines.

	VPIM is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice messaging networking protocol. The profile is referred to as VPIM   (Voice Profile for Internet Mail). This profile is based on earlier work in the Audio Message Interchange Specification (AMIS) group that defined a voice messaging protocol based on X.400 technology.  This profile is intended to   satisfy the user requirements statement from that earlier work with the industry standard ESMTP/MIME mail protocol infrastructures already used within corporate intranets.

2 THE VPIM INITIATIVE: 

Three years ago, it would have been hard to convince people that Internet protocols were the best way to move voice mail and fax messages. Three years from now, it may be hard to imagine a better way. The vehicle responsible for this potential transformation is Voice Profile for Internet Mail (VPIM), which defines an Internet standard for exchanging voice 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 Multipurpose Internet Mail Extensions (MIME)—have tremendous momentum and are becoming the common denominator. However, simply moving to an Internet standard is not enough. The ubiquity of the telephone and the wide-spread use of voice mail systems has to be taken into account—people are not about to stop using them. Therefore, VPIM specifies how messages are exchanged between mail servers—not the way these servers interact with client applications or the way they interface with the end user. This allows many different kinds of existing systems to support VPIM and also allows for future support by advanced desktop clients.

With VPIM, users of traditional voice mail systems can continue to access and operate their systems via the telephone, while users of the latest multimedia messaging systems use graphical PC screens and mouse clicks. VPIM simply lets these systems exchange messages across TCP/IP-based intranets and the Internet. 	

Because VPIM currently focuses on server to server message, exchange desktops will require VPIM helper applications to correctly record and playback applications. A subsequent revision to VPIM that addresses the specific needs transparent desktop multi-media message exchange is currently in the works. VPIM resolves long-standing difficulties in simply transporting messages between disparate voice mail systems, and enables inexpensive transport via TCP/IP intranets and Internets. 

It also facilitates intentional messaging: the creation and sending of voice messages without any real-time involvement with the recipient (or his/her voice mail system or answering machine). Sending an intentional message means not having to call the distant party, see if someone answers, ask for the person you want, find out they are not in, 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’s forwarding, 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 in widespread use among people who interact regularly. Short, directed, intentional voice messages have become the predominant way that workgroups accomplish their daily tasks in many corporate environments.

3 ANALOG NETWORKING (AMIS)
Analog networking is an easy and convenient way to network voice mail systems because voice mail systems already know how to receive phone calls and store incoming analog voice messages. 
With analog networking, a telephone connection between voice mail systems, such as the public switched telephone network (PSTN) is used to transfer messages between voice mail systems. No transcoding is required because the sending voice mail system calls the receiving voice mail system and sends the voice message as analog voice data. The receiving voice mail system answers the phone call and receives the analog voice data including DTMF codes for the mailbox number. 
In January 1988, an extended group of voice mail users and vendors, including OMD, met to outline an interoperability standard for voice messaging. Out of this group came the Audio Messaging Interchange Specification (AMIS). 
By supporting AMIS-analog networking, one vendor's voice mail system can exchange voice messages with any other vendor’s voice mail system that also supports AMIS-analog networking. Because analog networking is easy to implement, it has been supported by almost every voice mail vendor. However, to ensure interoperability between so many different vendors, when it comes to features, the AMIS-analog networking protocol only provides the least common denominator of features among all of the vendors.
AMIS-analog networking provides basic voice messaging between different vendor’s voice mail systems. This basic level of messaging includes sending, receiving and replying to voice messages. The AMIS-analog protocol does not support enhanced message delivery options such as: urgent messages, private messages confirmation of delivery or future delivery. Restrictions on the length and number of messages allowed in a single call makes AMIS-analog solutions more expensive than most proprietary networking solutions. Additionally, AMIS-analog does not support fax messages, spoken name confirmation or Dial-by-Name.

4 VOICE MESSAGING SYSTEM LIMITATIONS

The following are typical limitations of voice messaging platform, which were considered in creating this baseline profile.

1)	Text messages are not normally received and often cannot be easily displayed or viewed.  They can often be processed only via text-to-speech or text-to-fax features not currently present in many of these machines.

2) Voice mail machines usually act as an integrated Message Transfer Agent, Message Store and User Agent.  There is no relaying of messages, and RFC 822 header fields may have limited use in the context of the limited messaging features currently deployed.

3) Voice mail message stores are generally not capable of preserving the full semantics of an Internet message.  As such, use of a voice mail machine for gatewaying is not supported.  In particular, storage of recipient lists, "Received" lines, and "Message-ID" may be limited.

4) Internet-style distribution/exploder mailing lists are not typically supported.  Voice mail machines often implement only local alias lists, with error-to-sender and reply-to-sender behavior.  Reply-all capabilities using a CC list are not generally     available.

5) Error reports must be machine-parsable so that helpful responses can be voiced to users whose only access mechanism is a telephone.

6) The voice mail systems generally limit address entry to 16 or fewer numeric characters, and normally do not support alphanumeric mailbox names.  Alpha characters are not generally used for mailbox identification as they cannot be easily entered from a telephone terminal.

5 DESIGN GOALS

It is a goal of this profile to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the requirements for interoperability with current generation voice messaging systems.  This goal is motivated by the desire to increase the accessibility to digital messaging by enabling   the use of proven existing networking software for rapid development.

This specification is intended for use on a TCP/IP network; however, it is possible to use the SMTP protocol suite over other transport protocols.  The necessary protocol parameters for such use is outside the scope of this document.

This profile is intended to be robust enough to be used in an environment, such as the global Internet with installed-base gateways which do not understand MIME, though typical use is expected to be within corporate intranets.  Full functionality, such as reliable error messages and binary transport, will require careful selection of gateways (e.g., via MX records) to be used as VPIM forwarding agents.  Nothing in this document precludes use of general purpose MIME email packages to read and compose VPIM messages.  While no special configuration is required to receive VPIM compliant messages, some may be required to originate compliant structures.

It is expected that  a VPIM messaging system will be managed by a system administrator who can perform TCP/IP network configuration. When using facsimile or multiple voice encodings, it is suggested that the system administrator maintain a list of the capabilities of the networked mail machines to reduce the sending of undeliverable messages due to lack of feature support.  

6 VPIM’S FEATURES OVER AMIS NETWORKING
VPIM includes the basic messaging capabilities of creating, forwarding and replying to voice and fax messages over any TCP/IP network. It also includes many features that are not in AMIS-analog such as the ability to send a message to multiple subscribers, non-delivery notification, message privacy and sending priority. It allows an unlimited number of recipients for a single message. In all, VPIM supported 14 new functions not included in AMIS-analog. Below is a summary of VPIM's supported features:
- Sending voice and fax message
- Receiving voice and fax messages
- Replying to voice and fax messages
- Forwarding voice and fax messages
- Sending distribution voice and fax messages
- Delivery notification
- Non-delivery notification
- Full duplex message flow
- Message privacy
- Message sending priority
-Original message time stamp
- Separate originator’s text name
- Separate originator’s voice name
- Separate text subject
- Separate spoken subject
- Service notification
- Unlimited number of messages per call
- Unlimited number of recipients per call
- Unlimited message length

7 HOW VPIM WORKS?
7.1 ARCHITECTURE

IP NETWORK USING TCP/IP

                   VPIM
                                                  VPIM

                      
7.2 VPIM ADDRESSING
	RFC 822 addresses are based on the domain name system.  This naming system has two components: the local part, used for username or mailbox Identification; and the host part, used for global machine identification.

	The local part of the address shall be a US-ASCII string uniquely identifying a mailbox on a destination system.  For voice messaging, the local part is a printable string containing the mailbox ID of the originator or recipient.  While alpha characters and long mailbox identifiers are permitted, most voice mail networks rely on numeric mailbox identifiers to retain compatibility with the limited 10 digit telephone keypad.  As a result, some voice messaging systems may only be able to handle a numeric local part.  The reception of   alphanumeric local parts on these systems may result in the address being mapped to some locally unique (but confusing to the recipient number or, in the worst case the address could be deleted making the message un-replyable. Additionally, it may be difficult to create messages on these systems with an alphanumeric local part without complex key sequences or some form of directory lookup.

	The use of the domain naming system should be transparent to the user.  It is the responsibility of the voice mail machine to lookup the fully-qualified domain name (FQDN) based on the address entered by the user.

	In the absence of a global directory, specification of the local part is expected to conform to international or private telephone numbering plans.  It is likely that private numbering plans will prevail and these are left for local definition.  However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. The indication that the local part is a public telephone number is given by a preceding `+' (the `+' would not be entered from a telephone keypad, it is added by the system as a flag). Since the primary information in the numeric scheme is contained by the digits, other character separators (e.g.  `-') may be ignored (i.e. to allow parsing of the numeric local mailbox) or may be used to recognize distinct portions of the telephone number (e.g. country code).  The specification of the local part of a VPIM address can be split into the four groups described below:

     1) mailbox number
        - for use as a private numbering plan (any number of digits)
        - e.g.  2722@lucent.com

     2) mailbox number+extension
        - for use as a private numbering plan with extensions
          any number of digits, use of `+' as separator
        - e.g.  2722+111@Lucent.com

     3) +international number
        - for international telephone numbers conforming to E.164
          maximum of 15 digits
        - e.g.  +16137637582@vm.nortel.ca

     4) - for international telephone numbers conforming to E.164
          maximum of 15 digits, with an extension (e.g. behind a
          PBX) that has a maximum of 15 digits.
        - e.g.  +17035245550+230@ema.org

   	Note that this address format is designed to be compatible with current usage within the voice messaging industry.  It is not compatible with the addressing formats of RFCs 2303-2304.  It is expected that as telephony services become more widespread on the Internet, these addressing formats will converge.

7.3 VOICE MESSAGE CONTENT TYPES

   	MIME, introduced in [MIME1], is a general-purpose message body format that is extensible to carry a wide range of body parts.  It provides for encoding binary data so that it can be transported over the 7-bit text-oriented SMTP protocol.  This transport encoding (denoted by the Content-Transfer-Encoding header field) is in addition to the audio encoding required to generate a binary object.

	MIME defines two transport encoding mechanisms to transform binary data into a 7 bit representation, one designed for text-like data ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). While Base64 is dramatically more efficient for audio data, either will work.  Where binary transport is available, no transport encoding is needed, and the data can be labeled as "Binary".

	An implementation in compliance with this profile SHOULD send audio and/or facsimile data in binary form when binary message transport is available.  When binary transport is not available, implementations MUST encode the audio and/or facsimile data as Base64.  The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices. However, if a content is received in a transfer encoding that cannot be rendered to the user, an appropriate negative delivery status notification MUST be sent.

	The content types described in this section are identified for use within the multipart/voice-message content.  This content, which is the fundamental part of a VPIM message, is referred to as a VPIM voice message in this document.
 
	Only the contents profiled subsequently can be sent within a VPIM voice message construct (i.e., the mulitpart/voice-message content type) to form a simple or a more complex structure.  The presence of other contents within a VPIM voice message is an error condition and SHOULD result in a negative delivery status notification.  When multiple contents are present within the multipart/voice-message, they SHOULD be presented to the user in the order that they appear in the message.
8 VPIM CONFORMANCE REQUIREMENTS
	VPIM is a messaging application which must be supported in several environments and be supported on differing devices.  These environments include traditional voice processing systems, desktop voice messaging systems, store and forward relays, and protocol translation gateways.

	In order to accommodate all environments, this document defines two areas of conformance:  
	
	1. Transport and
	2. Content

	Transport conformant systems will pass VPIM messages in a store and forward manner with assured delivery notifications and without the loss of information.  It is expected that most store and forward Internet mail based messaging systems will be VPIM transport compliant.

	Content conformant systems will generate and interpret VPIM messages. Conformance in the generation of VPIM messages indicates that the restrictions of this profile are honored.  Only contents specified in this profile or extensions agreed to by bilateral agreement may be sent.  Conformance in the interpretation of VPIM messages indicates that all VPIM content types and constructs can be received; that all mandatory VPIM content types can be decoded and presented to the recipient in an appropriate manner; and that any unrenderable contents result in the appropriate notification.

 	VPIM end systems are expected to be both transport and content conformant.  They should generate conforming content, reliably send it to the next hop system, receive a message, decode the message and present it to the user.  Voice messaging systems and protocol conversion gateways are considered end systems.

	Relay systems are expected to be transport compliant in order to receive and send conforming messages.  However, they must also create VPIM conforming delivery status notifications in the event of delivery problems.

	Desktop Email clients that support VPIM and are expected to be content conformant. Desktop email clients use various protocols and API's for exchanging messages with the local message store and message transport system.  While these clients may benefit from VPIM transport capabilities, specific client-server requirements are out-of-scope for this document.
9 SECURITY CONSIDERATIONS
	Both Internet mail and voice messaging have their own set of threats and countermeasures.  As such, this specification does not create any security issues not already existing in the profiled Internet mail and voice mail protocols themselves.  This section attends only to the set of additional threats which ensue from integrating the two services.

9.1 SPOOFED SENDER

	The actual sender of the voice message might not be the same as that   specified in the Sender or From header fields of the message content header fields or the MAIL FROM address from the SMTP envelope.  In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem.  In addition, the recognition of the senders voice may provide confidence of the sender's identity irrespective of that specified in Sender or From.  It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication.

9.2 UNSOLICITED VOICE MAIL

		Assigning an Internet mail address to a voice mailbox opens the possibility of receiving unsolicited messages (either text or voice mail).  Traditionally voice mail systems operated in closed environments and were not susceptible to unknown senders.  Voice mail users have a higher expectation of mailbox privacy and may consider such messages as a security breach.  Many Internet mail systems are choosing to block all messages from unknown sources in an attempt to curb this problem.

9.3 MESSAGE DISCLOSURE

	Users of voice messaging systems have an expectation of a level of message privacy, which is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by users SHOULD be preserved as much as possible.

10 PROTOCOL RESTRICTIONS

	This protocol does not limit the number of recipients per message. Where possible, server implementations should not restrict the number of recipients in a single message.  It is recognized that no implementation supports unlimited recipients, and that the number of supported recipients may be quite low.

	This protocol does not limit the maximum message length. Implementers should understand that some machines will be unable to accept excessively long messages.  A mechanism is defined in the RFC 1425 SMTP service extensions to declare the maximum message size supported.

	The message size indicated in the ESMTP SIZE parameter is in bytes, not minutes or seconds.  The number of bytes varies by voice encoding format and includes the MIME wrapper overhead.  If the length must be known before sending, an approximate translation into minutes or seconds can be performed if the voice encoding is known.

	The following sections describe the restrictions and additions to Internet mail protocols that are required to be compliant with this VPIM v2 profile. Though various SMTP, ESMTP and MIME features are described here, the implementer is referred to the relevant RFCs for complete details. It is also advisable to check for IETF drafts of various Internet Mail specifications that are later than the most recent RFCs since, for example, MIME has yet to be published as a full IETF Standard.

VPIM!

11 EXAMPLE PRODUCTS OF VPIM CONFORMANT(EXCHANGE 2000)

Applications and Services
 - e.g. notifications, agents, CRM

Telephone Network
Telephone (PSTN, PBX, etc), Wireless (GSM, etc)

Voice Mail Systems
 PBX’s, switches, etc
 tightly coupled clients 
(i.e. telephones)

Internet, Intranet
Internet (HTTP, VoIP, SMTP, etc)

UM Server 
- storage, streaming media, VPIM interoperability, 
message transport, directory, etc

Clients
- e.g. OWA, Outlook 2000, Outlook Express

12 EXAMPLE SCENARIO OF VPIM’S USAGE

	To understand the relationships among messaging and directory servers, let’s trace their use in a typical user situation. Say you’re out of the office when you spot an attractive new French restaurant. From a pay phone, you call me suggesting we have lunch there tomorrow. Since I’m out of the office when you call, you leave me a traditional voice message. When I call in (from another pay phone) to check my messages, the lunch date sounds great, and I immediately think of Giselle, a new friend and fellow gastronome I want to bring along. Here’s where VPIM helps. While still logged into my corporate, VPIM-enabled voice mail system, I can create and send an intentional voice message to you, and then another one to Giselle.

	To create a message to you, I need to enter your regular phone number (remember, you called from a phone booth). My voice mail system knows (from my stored profile) that it should look first in my personal directory for entries, then in the corporate one and then in a shared public directory. It finds your VPIM address in my personal directory, either because I put it there via a browser directory edit tool or because it was cached from the business card content of an earlier VPIM message— that content contained your name, phone, email and VPIM addresses, and your spoken name. To verify that you are the intended recipient, my voice mail system speaks your name to me, and I confirm by pressing a key or speaking a prompt. The system sends the message, and I stay logged on to create and send a voice message to Giselle. She has a voice mail account through her phone company, a number which I haven’t yet entered in my personal directory.

	When I enter her number, my voice mail system doesn’t find Giselle in my personal directory or in the corporate directory. Fortunately the corporate directory has X.500 “powers,” so it knows which service provider in the shared public voice message directory has Giselle’s entry.

	After retrieving this number, my corporate voice mail system encodes my voice message into a VPIM MIME part and sends it via SMTP over the Internet to Giselle’s phone company’s gateway, where it is sent on to her voice mail box. (For efficiency, my mail system also saved Giselle’s directory information into my personal directory so that future references are faster and cheaper. This will also allow me to later edit the entry, via my browser.)
	Still logged on, I decide on an impulse to also send a voice message to a friend in France telling him of the anticipated dining delight. This message is moved in a similar way to a voice mailbox supported by a VPIM-enabled service provider in France. When you get back to your office, you fire up your PC and log into your universal message system. The GUI on your IMAP4 or POP3 client indicates a voice message from me, so you click on it with your mouse. Your mail client application invokes a helper application that plays the VPIM MIME message through your PC speakers. You select the “reply via voice mail” option onscreen, so that your message will go back to my voice mailbox. (In your directory, you may have several addresses and phone numbers for me, so you may have to choose one.)

	Your client mail application also has a helper app to create VPIM MIME messages so you record your response via the workstation microphone and it is sent via standard Internet back to my VPIM voice mailbox. Tomorrow we lunch with Giselle at the Fois Gras!

14	SUMMARY

While not yet complete, the picture of how VPIM and open directory services increase the 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 and gateways to find out which departments and workgroups are now using or could benefit from intentional voice messaging. Analyzing call detail reports would identify frequent, short calls 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). Because messaging traffic is stored and forwarded, it can be sent at off-peak intervals and prevented (by router parameters) from interfering with higher-priority, or real-time traffic. 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 on a broader basis.
Directories present challenges to the organization that include, but go well beyond, voice messaging.
VPIM-capable gateways and servers will soon be available to improve existing message server connections and facilitate enhanced messaging applications. RFPs for voice message systems should insist on VPIM and LDAP support that includes spoken name for all directory entries.