The Voice-Mail IAP

This document describes the specifics of the Voice-Mail IAP. For a general description of an IAP, refer iap.html.

The Voice-Mail IAP is a primitive voice-mail service in itself. The only interface it has (for voice-mail) is the IAP interface. The voice-mail records and stores voice-mail messages. It supports only incoming calls (is a server IAP) and incoming DTMF -- none in the outgoing direction.

The specifics of the Voice-Mail IAP are:

• It can operate with a "Distributed Hashtable" backend or a "file-based" backend. For details on the distributed hashtable, refer Steve Gribble's home-page.
• Since the DDS (Distributed data structure) package is not part of the release, and to avoid the setup of an additional piece of software, the voice-mail IAP is setup to operate with a file-based backend by default (this is controlled by a #ifdef DDS in Vm_Iap.jc).
• Neither the DDS, nor the file-based backend have any support for transactions, and the voice-mail IAP has not been written with enough care to get around this -- hence the voice-mail could get corrupted due to crashes.
• The voice-mail IAP always operates with "gsm" as its end-point format.
• Voice-mail opeartion during a session is through DTMF tones from the user at the other end.
• The implementation of interfaces called by the APC is very similar to that of the VAT IAP.
• The voice-mail IAP has an interface for administering the service. This interface is currently very limited -- supports only addition of users and retrieving information about existing users. There is a corresponding AdminTool program to act as client to this interface. The AdminTool has a console based interface.

Voice-mail operation

The voice-mail can be called in two different ways. The first is when the user directly dials into the voice-mail service. The second is when a user calling another is redirected by the callee's preference registry to the voice-mail. In the first case, the callee of the call is the voice-mail itself. In the second case, the callee id would be that of the user who the caller was trying to reach. The voice-mail uses this information to put itself in one of two modes of operation: (a) voice-mail access, or (b) voice-mail recording.

In the first case, the user can access her stored voice-mail messages or record a new playback message. In the second case, the caller hears the callee's playback message, and is allowed to record a message for the callee.

In the first case, the DTMF tones used are the following:

• '1', '#' -- for next message
• '2', '#' -- for previous message
• '3', '#' -- mark message as deleted
• '6', '#' -- record playback message
• '7', '#' -- stop recording
• '9', '#' -- expunge messages marked deleted
• '*' -- to cancel and start over the command again

Obviously, this interface is not a complete one. Also, there is no interactive system to guide the user. These are possible additions to the IAP.

The files

• Vm_Iap.jc -- the main file with the interfaces for calls from the CA and the APC.
• vm_thr_class.java -- the file implementing the per-session thread -- collects incoming DTMF tones and processes accordingly.
• vm_iap_ms_class.java -- the per-session state
• vm_iap_msg_state.java -- manages collection of all session states.
• VMUserInfo.java, MsgInfo.java -- structures to carry info about a user or about a message.
• VMAdminIF.java -- The interface for administering the voice-mail service.
• AdminTool.java -- the client for administering the voice-mail service.
• VMAdminException.java -- thrown by VMAdminIF routines.

Running the Voice-Mail IAP

iceberg.iap.vm_iap.Vm_Iap voice-mail-files-directory ipop-host[:port]

Voice-mail message files and meta-files

Each user has a file "uid.info" with the following bytes in it: "uid:quota:playback_msg:num_msgs:msg1_id:msg2_id:...". There is no terminating new-line. Each message is identified by an id (given at the time of recording). Associated with each message is a file "msgid.msginfo" with the following bytes in it: "caller:date:status:length". Again, there is no terminating new-line. The date is in the format of a long integer (returned by System.currentTimeMillis() in java). The status is one of "NEW", "READ", or "DELETED". The length is in bytes. Each message is stored as a separate file "msgid.msg".

Naming service and preference registry entries

Since the voice-mail IAP has an identity of its own (that is, users may try to reach the mediamanager IAP as an entity), it needs a naming service entry and preference registry entry.

Naming service entries

The naming service entry is of the form:

dn: uid=vm, l3=cs, l2=berkeley, l1=edu, type=uniq
uid: vm
iPOPUrl: jake.cs.berkeley.edu:9900/iceberg.ipop.CAD
objectClass: uidobj

You can also add a separate entry for any of the other name-spaces. For instance, the mediamanager IAP can be assigned a cell-phone number in the example cell-phone number space (see cpnums) by adding the entry:

dn: cpnum=864, type=gsm
aliasedObjectName: "uid=vm, l3=cs, l2=berkeley, l1=edu, type=uniq"
objectClass: alias

For information on adding naming service entries, refer the naming service documentation).

Preference profile

To add a preference profile for the mediamanager IAP, use the preference manager. The profile for this could be very simple with only one "outgoing interface" and a single rule specifying that to be the default. See the preference manager documentation for details on adding preference profiles.