Universal Inbox

- Bhaskaran Raman, Randy Katz {bhaskar, randy}@cs.berkeley.edu
ICEBERG, EECS, UCB.

Today, there are widely varying technologies, access methods and end devices for communication. A end user may be reached via a range of mechanisms and end-points: e-mail, cell-phone, pager, IP-phone call, POTS phone at home, POTS phone at office, POTS phone at a hotel during travel and potentially several others as well. A Universal-Inbox (U-Inbox) integrates all these technologies - a user can receive incoming calls on any of these end points based on her preferences. User preferences can be specified dynamically. We call this personal mobility.

In this project, we have built a prototype Universal-Inbox application. There are issues of naming, extensibility, scaling and fault-tolerance in such a communication infrastructure. In this paper, we describe how these issues and others were addressed in our initial design.

Introduction & Motivation

Today, there are widely varying technologies, access methods and end devices for communication. Consider the following scenario. A user has an office-phone, a desktop at his office, a home phone, a home PC, a cell-phone, an e-mail account and a voice-mail facility. Ideally, this particular user would like to manage incoming phone calls as follows:

All calls during day-time should be redirected to his office-phone to be handled through his secretary. But a specific conference call should be redirected to his desktop beside him.
In the night, when he's at home, all incoming calls should be received at his home-phone. Again, a particular conference call that includes video should be received at his home PC.
When he's asleep, he wishes to receive all calls as voice-mail - except for urgent calls from his boss.
At any other time (like while shuttling between home and office), calls should go to his cell-phone.
Incoming e-mails normally go as e-mails. E-mails that are marked important by the sender are treated specially. Their "subject" lines are converted to voice and read out to the user through the cell-phone.
The above rules apply only for the callers the user knows of. On receiving a call from an anonymous person, the caller must be asked to leave a message - which would be converted to text and sent as an e-mail.

Clearly, the existing communication infrastructures are far from providing such a rich functionality. There is no universal mechanism to glue the different technologies: POTS phone, IP-phone, cell-phone, e-mail, pager, FAX etc. In this project, we are looking at issues that arise when we try to build a "Universal-Inbox" integrating these technologies. Such a "Universal-Inbox" provides personal mobility: the network redirects a call to an appropriate end-point depending on user specified preferences. Users can specify and change their preferences dynamically.

There are several issues that need to be addressed:

Naming: The issue of mapping the "addresses" of different communication end-points (e.g. phone number & e-mail address) onto the same user.
User Preference Specification: How does the user specify personalized preferences to redirect incoming calls to a preferred end-point? What are the mechanisms that must be provided to support user policies that are dependent on caller, time of day and other factors?
Scalability: The issue of making such a network service highly available and incrementally scalable as more users are added to the system.
Fault Tolerance: The POTS achieves a high level of reliability through replication of components. What is the model of fault-tolerance and mechanism for achieving it?
Extensibility: The communication infrastructure should be able to accommodate a new types of end-point in the future.

We have built a test-bed that provides inter-connection between GSM cell-phones and computers on the Internet through a GSM base-station and a GSM-IP gateway. We plan to add access to a PSTN network through a H.323 gateway. Using this testbed, we have built a prototype "Universal-Inbox" in order to gain insight into the above mentioned issues.

The rest of this document describes the initial design of the prototype that we have built.

Components of the Initial Design

Naming

Each communication technology has its way of naming its end-points. For example, an e-mail address looks like bhaskar@cs.berkeley.edu while a cell-phone or POTS phone number looks like 510-642-9076. We need a mechanism to map the different end-devices owned by a user to the same user identity.

We use a mechanism similar to IDNP (Iceberg Domain Naming Protocol) proposed in [1]. We use the mapping Type-Specific-Id <==> Unique-Id. The "type-specific-id" itself is a tuple <type-id, type-specific-name>. For example: <EMAIL-TYPE, bhaskar@cs.berkeley.edu> and <CELL-PHONE-TYPE, 510-642-9076> are two different type-specific-ids that map to the same end-user with the unique-id bhaskar.

Specifying User Preferences

Each incoming call has to be redirected to an end-device of the callee. The receiving end-point has to be chosen according to the callee's preferences. We call the chosen end-point the preferred end-point. In the simplistic scenario described earlier, the preferred end-point was a function of caller-id and the time-of-day. In a realistic scenario, the preferred end-point could depend on many more factors including:

callee's and caller's locations
caller's end-point type
caller's preference, if any
network reachability information (the callee may have moved out of coverage area of her cell-phone carrier and may wish to redirect the call to a voice-mail system).
network cost, QoS, bandwidth, latency information

Note that the list of factors that decide the preferred end-point would differ greatly from one user to another. More importantly, the list may grow in the future. Hence the preferred end-point cannot be specified using a static database. We need a dynamic script that can be run to decide the preferred end-point for every incoming call.

In the first prototype of the universal-inbox, we have not designed or used a script. Instead, we have hardcoded the script in java program that returns the preferred end-point as a function of the callee.

Data-type Conversion

In a communication system that has heterogenous end-points, there would be different data types. For example, the data type associated with a cell-phone is a GSM voice stream; the data type associated with a POTS phone is a 64kbps voice stream and the data type for email is plain-text. To receive a voice message as an email, we have to convert a voice stream to text.

To provide independence across caller and callee end-point, we need a mechanism for data-type conversion. We are using the concepts of Operators, Connectors and Automatic Path Creation (APC) developed in the NINJA project [2]. An operator is a program or module that converts a particular type of data to another. It is stateless. A path consists of many operators chained together. In a path, the output type of one operator is compatible with the input type of the next. Operators run in a computational infrastructure that provides fault-tolerance and incremental scaling. APC is a mechanism that chooses a particular set of operators and strings them together to achieve the desired data-type conversion.

Operators are strung together using connectors. For now, the only kind of connectors prototyped are Java-RMI connectors. For real-time data-type conversions, especially codec conversions, we need a connector based on a protocol like RTP.

Scaling and Fault Tolerance

A communication system has to scale to a large number of users. Importantly, it has to scale incrementally. Here too, we leverage the concept of a Service from the NINJA project. A service runs in an execution environment called an iSpace. The iSpace provides the service with properties like scalability and high availability. There are several "services" that run as part of a u-inbox infrastructure. These are described individually in the next section.

Fitting the Components

Figure 1 shows the overall design picture. For each communication end-point, a U-Inbox Service exports an interface to the outside world. The U-Inbox Service handles both incoming as well as outgoing calls. The place where the service runs depends on the end-point. For interfacing with a cell-phone, a U-Inbox service may be configured to handle calls from/to the coverage area of a few base-stations. For interfacing with POTS phones, the U-Inbox service may be run at the H.323 gateway. In the case of IP-phone where the end-point is a desktop, the U-Inbox service could run at the desktop itself.

For a single call, the U-Inbox service at the originating point of the call talks to the U-Inbox service at the destination end-point to do call setup. The call signaling protocol between the two U-Inbox services is currently a simple java-RMI call. The U-Inbox service (a java program) exports an RMI interface for handling incoming calls. It acts as an RMI client for outgoing calls. The call setup protocol has to be a full fledged IP signaling protocol like SIP or H.323.

The Directory Service stores two sets of mappings for each user. Firstly, it stores the mappings between the type-specific ids of the end-devices of the user and the unique id of the user. Secondly, it maintains the user's preferences to decide the preferred end-point for incoming calls. The APC Service does the path creation for a given input type and output type. The directory service and the APC service could run on any machine. They are just java programs that export an RMI interface.

An Example Scenario

We describe an example of a call setup in the above design of the U-Inbox. The sequence of events is shown in figure 2.

The call originates from the cell-phone.
The associated U-Inbox service intercepts the call.
The directory service is queried to get the preferred end-point of the callee.
The U-Inbox service associated with the preferred end-point is invoked through an RMI call. This RMI call is made by the U-Inbox service at the caller side.
The callee side U-Inbox service invokes an instance of the APC service to do the path creation for data type conversion.
The call signaling is done to the other end-device.
The RMI call made by the caller U-Inbox to the callee U-Inbox now returns. This completes the signaling. The call can now proceed.
The call tear-down involves a similar sequence of events. There is no need to invoke the directory service though.

Implementation

The first prototype of the U-Inbox has been implemented. The BTS-IP testbed has been used to include cell-phones in the range of devices. Other end-points include: e-mail, voice-mail and IP-phone. For voice over IP, we use vat [4]. Vat does not have any call signaling protocol. A U-Inbox service was built as a wrapper around vat to provide the required call setup signaling as well as to integrate with the rest of the U-Inbox communication end-points.

Since no real-time connector (to connect operators) is in place yet, no online codec conversions are possible yet. All voice communication use the GSM codec.

The directory service maintains the name-mappings as well as the user preferences. The preference scripts are currently hard-coded in the directory service code.

To do

Real-time data-type conversion using real-time connectors.
The different services dont run in an iSpace yet. But it would not take too much to make them run as iSpace services.
The preference scripts for each user are currently hardcoded in the directory service. A suitable scripting language has to designed and used.
The mechanism for deciding the preferred end-point is incomplete in several respects:

We have not thought through how shared phones such as those in offices can be handled.
It is not fully clear how network level information such as bandwidth, latency, QoS and reachability can be used as inputs in deciding the preferred end-point.

The signaling protocol between Univ-Inbox services should be an IP-signaling protocol like SIP or H.323.
While DTMF signaling goes through the data channel in the POTS network, the same is not possible in the non-isochronous internet world. Like in GSM's air links, the DTMF tones must be as part of the control channel.

Send comments and suggestions to Bhaskaran Raman (bhaskar@cs.berkeley.edu)
Last Updated: Jan 14 1999