Internet Telephony
CS519 Fall 1998

Overview

The class will be divided into groups of 20 students (some groups may be larger to accommodate the actual class size). Each group will be further subdivided into teams of two (rarely three) that work together. The goal is to encourage competition between groups, and cooperation between teams. All members of a team will get the same project grade.

All code should be written in Java, unless speed considerations require C/C++.
 
 

The project

Internet telephony is a not a well-defined term. In this project, we will take it to mean the use of Internet for telephony, and applications that span both the Internet and the telephone network. An overall view of Internet telephony according to this definition is shown in the figure below.

On the top left, we show the existing telephone network, and on the top right, the existing Internet. The campus PBX is connected to the telephone network, and the campus router to the Internet. These, in turn, are connected to a local PBX and a local router. Finally, at the bottom level, telephones are connected to the local PBX, and hosts to the local router. Data flow between the Internet and the telephone network is through a gateway that translates voice samples to IP packets and vice versa. Telephone users can talk to other telephones, or to workstations reachable from the gateway. Symmetrically, users can use workstations to reach other workstations or telephones. The gateway should allow telephone numbers to be associated with IP addresses so that samples destined to a particular number can be properly encapsulated. This requires a handshake between a control component running at every host, the gateway controller, and the PBX controller. These controllers, shown at the bottom of the picture, are responsible for basic control functions, such as call establishment, as well as more complicated ones, such as failure detection and automatic call forwarding. Note that the local router is also controlled by a controller. This controller is supposed to set up state in the local router to allow it to provide quality of service in the Internet fragment under its control. We will attempt to provide a router with this capability for this project.
 
 

The components

We now describe the basic components of the system. A high-level object template describes interfaces between the components. This will let you get started in your Java classes. You are required to extend the template, and can make any changes you want. We may, however, require you to justify the changes.

1. Data exchange on the Internet

The goal of this component is to carry packets containing voice data (voice packets) between two hosts on the Internet. Since voice packets may be lost, delayed, or reordered, the sender and receiver should collaborate to counteract these problems using forward error correction, adaptive playout, and buffering, respectively. The data exchange team should also arrange to acquire and play voice data in a workstation (using Jdirect). The basic steps that have to be carried out by this component are voice acquisition, coding, packetization, streaming packets on the Internet, receiving and reconstructing voice packets, decoding, and playout.

Voice sources: file, microphone and network. Voice destinations: file, speaker and network. Voice channels are unidirectional. The layer above you can ask you to set up a connection between any source and destination.

Class Source:
        {Constructor();
        Destructor
        }

Class Destination:
        {Constructor();
        Destructor
        }

Class Connection:
        {Constructor();
        SetParameter(); //bytes per packet (for network connections) or other
                   //parameters that can be varied
        Activate();     //handing over the control of the processor to the connection
                   //Does not return until the connection is terminated somehow.
        Stop();         //tear down a data path
        Destructor
        }

You should cooperate with the gateway group (see below) for defining the network data format.
 
 

2. Signaling

Signaling is the basic functionality in the control plane. It allows voice calls to be set up in the Internet and the telephone network, and the gateway to associate telephone numbers with IP addresses and vice versa. Consider a call that originates in the telephone network and terminates in the Internet. When the call arrives at the local PBX, it is associated with one of the lines leading to the gateway. A signaling component on the PBX controller notifies the gateway controller that the call to a particular destination address (encoded as a telephone number) is arriving on a particular telephone line. The signaling component should use a directory service (described later) to map this telephone number to an IP address. The gateway should set up a translation between the appropriate telephone line and the IP address, so that the proper actions can be taken in the data plane. In parallel, the signaling component on the host is contacted to alert the user about the incoming call. If the call is not accepted, the calling party on the telephone network should get a busy tone. Signaling must carry out these actions. Calls initiated from a workstation require a symmetric signaling action. The team implementing this component should be careful to take care of error conditions, race conditions, and asynchronous actions, such as hanging up the telephone.

All the entities participating in the communication process have a signaling part. You have to design a protocol used by the signaling parts to communicate with each other. This includes possible states of the communicating entities, message syntax and semantics. The signaling system should also be prepared to handle multi-point telephone calls. It should be possible for the management software to interrogate the signaling entities. The interface for these calls is to be designed by the management team. Your code is supposed to tell the accounting software of any relevant events.

On the PBX, the signaling team will also provide the "main program" controlling the PBX. Since no one "uses" your code we do not provide an interface specification here. The PBX signaling code may also control the bandwidth reservation at the router.

On the gateway, the signaling team will also provide the "main program" controlling the gateway operation. Since no one "uses" your code we do not provide an interface specification here. This part of the signaling code should guide the gateway when setting up multi-point calls.

On the desktop machine, the signaling team will provide an API available to the other applications and a sample application: Internet telephone.

Class DesktopSignaling:
        {Constructor();
        RegisterUpcallForIncomingConnections();
        Dial();
        Hangup();
        AcceptCall();
        RejectCall();
        Destructor();
        }

In case there are many applications running on a desktop computer, their signaling parts should be at least aware of each other. The design of the API that the conference group needs is their task. The implementation is your's.

3. Data flow in the gateway

The gateway is connected to eight telephone lines and an Ethernet. In the data plane, it has to take voice samples arriving from the telephone network and place them in IP packets, and vice versa. This has to be done with great care, because the gateway should introduce as little delay as possible. Thus, transmission both of voice samples and of IP packets should be carefully scheduled. This team will be responsible for completely understanding and programming the data paths in the Dialogic gateway card. The team should also allow data flow for multi-point telephone calls (i.e. bridged conference calls).

You should cooperate with the data team (team 1) for defining the network data format. The normal connections through the gateway are bi-directional connections with one phone line on one end and an IP address at the other. Multi-point connections can have zero or more desktop machines participating and there can be zero or more phone lines associated with such a connection.

You must implement the functionality at least using the basic dx_ calls to the D/41E board.   When that is complete, you may go on to try using IPLink which implements  in hardware sending and receiving IP packets containing the voice samples. The Dialogic boards have been installed in the vada computer in the Systems Lab.

Class Gateway:
        {Constructor();
        SetupConnection(); //sets up the data path of a normal connection through the gateway
        TearDownConnection();
        SetupMultipointConnection();
        JoinMultipointConnection();
        LeaveMultipointConnection();
        ChangeCurrentSpeaker();
        TearDownMultipointConnection();
        }

4. Directory service

A directory service translates between identifiers: between names and IP addresses, telephone numbers and IP addresses, and between names and sets of telephone numbers that that name can be reached. A distributed directory service is made up of multiple components that cooperate with each other to provide the illusion of a single centralized directory. The team providing this component should either design a new directory service from scratch, or extend DNS resource records to provide this service. The team should deal correctly with DHCP addresses, which can result in the same host using different IP addresses at different points in time. The directory service should also deal with issues of authentication, security, reliability, and robustness to failure.

The directory system should take into consideration the case of "roaming" users. If a user signals his/her presence from another computer than expected, his/her calls should be directed to the new computer (or to a certain phone). Besides writing the directory service system, the directory group is supposed to provide "stub"s to the applications using their services. If you decide not to use DNS you should design your own protocol of communication between the server(s) and the stubs on the clients. Since almost all other teams depend on you it is important that you come up early with a stable API for the client stubs (and a null interface).

Class DirectoryStub:
        {Constructor();
        DeclareIdentity(); //Declare your identity public
        GetLocationOfSubscriber();
        ChangeLocationOfSubscriber();
        GetSubscriberAssociatedWithNumber();
        ListAllSubscribers();
        }

5. Billing, accounting, and pricing

This team should work with other teams to insert the appropriate hooks in their code to allow billing and accounting. Each call should be logged in a database that can recover from host-crashes (i.e., cannot be in RAM). Calls should be associated somehow with users, and bills should be generated to recover costs. This team can also experiment with different pricing policies for Internet-based calls, since there is no standard for such calls. The accounting group should provide stubs for the signaling team so they can report all significant events. It is your responsibility to combine the low-level data from the logs (IP addresses, etc.) with the data the directory service provides you so that you charge the proper subscriber (his/her IP address might change over time). You should generate reports and bills. You are supposed to design the interfaces of your stubs based on what you want to be told. Design an authentication protocol so that you cannot be fooled by malicious users pretending to be the PBX.

6. Management and integration

The integration team should work with all other teams to harmonize their interfaces. They should remove inconsistencies so that, at the end of the semester, code from all the teams can be plugged together. This team is also responsible for network management. The team should insert management hooks in all other components to allow application-specific management. This, for example, would allow a network manager to determine which hosts are up, which calls are going through the gateway, and which users are available. The network manager should also provide a single point of control for setting system-wide parameters such as for voice-packet size and security keys. You are supposed to be the one asking for information, no application will volunteer to notify you of a change in state. You are supposed to tell the other teams what information you need and agree upon some functions they should implement (you design your hooks). However you are the one supposed to write stubs located on the client machines, responsible for communicating with the manager application.

7. Voice-email gateway

The voice-email gateway allows email and telephone calls to interoperate. Incoming email should be made accessible from the telephone network (by means of an online menu), and incoming telephone messages should be sent as attachments to email messages. The menu you are supposed to implement for purposes of checking e-mail via a phone call is a voice menu. You will accept input from the user in form of  tones, and give feedback on the operations you perform as (spoken) sentences. The team should design authentication mechanisms to prevent unauthorized access to messages, and allow personalized voice greetings for telephone callers who want to leave a message. We will provide a text-to-speech program to allow email messages to be read aloud and also a RealAudio server to store and stream audio.

8. Multiparty audio conferencing + whiteboard

The title says it all. The telephone network carries the voice between participants, and a shared whiteboard allows participants to share a graphic workspace. Exisiting whiteboard applications such as wb or Web-based whiteboards, may be reused. The team should design and implement a conference control application to allow participants to join and leave conferences (some conferences may be private, and not allow random users to join), and to allow a speaker to cede control to one of a set of waiting speakers. The control scheme should also allow users who may not be accessible on the Internet to have an audio-only connection to a conference. You should design the interface describing what you expect from the signaling team as concerning the setup of multi-point connections.

9/10. Unspecified applications

These teams can design and implement any application they wish, as long as it makes non trivial use of the Internet and the telephone network.

How to do the project

First, figure out which teams depend on you, and which teams you depend on. The table below might be helpful. Tell the teams you depend on what functionality you need from them, and, in turn, take note of the functionality that you will need to provide teams that depend on you. Use the discussion groups we will provide to converge on this functionality. It may also help to have a group-wide meeting where all the functionality is discussed in parallel. At the end of this round of discussions, you should have the first cut at the interfaces. Remember that this interface specification is critical to the success of your group.

Second, implement a null interface. This is the minimum functionality necessary to implement the interface. For example, the null directory server always returns the same translation, which can even be stored in main memory. The idea is that the null interfaces can be plugged together to build a compilable system, that may not actually work. However, it does exercise the basic interfaces, and allows teams to work in parallel.

Third, extend the null interface with new functionality. Make sure that your code is checked into a system such as CVS, so that other teams can access it. Document your work. Write test programs that exercise your code before you check it in. Read the sections referring to other teams' work too. It helps if you know what the other groups are working on.

Finally, set aside time to put together and test the entire system.

Your code has to run on:

• D - a desktop computer
• G - on the gateway (the computer with the dialogic card)
• P - on the computer controlling the PBX
• S - on some separate server (directory server, management station, accounting server, etc.)

Interacting normally means using (calling) the code they have to write. Where marked with a star (*) it means communicating over the IP network. Some of the teams are required to implement stubs. Stubs are small pieces of code that reside on the same machine as a client of a certain service. When the client wants to make a request to a server, it calls one of the functions provided by the stub, just llike calling any other local function. The stub doesn't process the request. It contacts the server instead, using the network. When the server sends the answer back, the stub returns it to the client. When designing a stub you have to take care of two aspects: describe the functionality you make available to the client (specifications for the API you provide) and design a protocol that will be used for communication between the stub and the server. Any change in the API has a direct effect on other teams, while a change in the protocol doesn't, because the team writing the stub is allways the same with the one writing the server. A good design for the stubs takes into consideration the possibility of errors (the server is down, the network is down, etc.).