[Indigo]<Voice>Stewart>ep5.bravo!1

File: EP5.bravo
By: L. Stewart
Date: June 22, 1981 3:40 PM

This contains a description of what the first working Etherphone is supposed to do. (In fact, it will take two working Etherphones!) Naturally, there are an immense number of options to sort over. I have tried to choose one set, without being too careful about it.

The first Etherphone consists of an Alto I processor plus the Auburn audio board originally intended for the Alto II. The Etherphone program will not use either the display or disk, but will use the keyboard. The Etherphone includes a local telephone set (handset plus switchhook) and a centrex telephone line. We plan to build two to five of these models. There is some amount of analog circuitry for connecting the centrex line that does not yet exist, but everything else is available.

The first Etherphone has all the functionality of the existing office phones, but nothing else. It provides plain old telephone service. Calls from the Etherphone to another Etherphone take place over the Ethernet. Calls to or from other locations use the Etherphone telephone set, but actually place the call over the centrex line. The Etherphone is the only phone in the office. The intent of this arrangement is to produce a real system, instead of a demonstration model. If an Etherphone could talk only to other Etherphones, we would not get much use out of the two to five we plan to build; members of the audio project do not make enough phone calls to each other to make heavy use of the system, but they do make a few such calls, plus a lot of others. We intend to construct this prototype to give the appearance that there are a lot of Etherphones, while there may only be a few to start.

The POTS functionality does not sound like much, but there are a lot of details. We break down the basic functionality into three areas: supervision, connection, and transport.

Transport refers to an Etherphone to Etherphone connection over the Ethernet. The process consists of managing a full duplex 64,000 bits per second data stream with small controlled delay. We feel that about 50 packets per second will be necessary, giving about 40-50 milliseconds of end to end delay (one packet plus slop). On top of the basic requirement for a fairly large number of packets per second, we want to add silkence detection. Silence accounts for something over 40% of a typical full duplex call. Simply not transmitting the bits for a silence interval could nearly double the capacity of an Ethernet for voice traffic.

Supervision refers to the management of basic control functions: when is the phone off hook, provision of dial-tone, reading the pushbuttons, generating signalling tones, etc. This is a larger task than otherwise because we must talk to the centrex line in order to make a believable system.

Connection management refers to all the problems of taking the button pushes from the local phone (keyboard) and using the information to place a call. In the case of Etherphone to Etherphone communications, call placement would be accomplished by some form of the roundezvous protocol. In the case of calls using the centrex line, signalling information must be sent either by dial pulses or by DTMF.

We now turn to some descriptions what the Etherphone does

Remember that this first system behaves just like an ordinary telephone. In order to place a call, the user first picks up the handset. The computer detects the closed switchhook contacts and begins to generate a locally produced dialtone. Just as in a standard phone, the dialtone indicates to the user the systems readiness to place a call. After getting dialtone, the user can use the keypad (keyboard) to dial a number. Our current proposal is for numbers like 3XXX to refer to other etherphones while other numbers refer to use of the centrex line. In either case, the computer must generate DTMF tones for the user to hear while he is pushing buttons. If the first digit is not a 3, the Etherphone immediately takes the centrex line off-hook and replaces the local dial-tone by a full duplex audio path between the local handset and centrex. The computer continues to generate tones according to the buttons and sends those tones both to centrex and to the local handset. For a centrex call, the Etherphone does nothing else until the switchhook is again open. If the first dialed digit is a 3, the Etherphone accumulates 4 digits and interprets the last three as an ethernet host address. A roundezvous protocol is used to establish an ethernet connection to that address. If there is no response, a reorder (fast busy) tone is generated locally. If the destination Etherphone is in use, either by another Ether-call or by a centrex call, a busy tone is generated. If the remote Etherphone is free, a ringing tone is generated and the remote Etherphone generates an audible ring. Once both Etherphones are off-hook, a full duplex audio path is established, using 64,000 bits per second mu-law coded audio. About 50 packets per second in each direction will be necessary to keep the delays low. Silence detection will be used to reduce the total 100 packets per second requirement.

If ringing is detected at the centrex line, the Etherphone generates an audinble ring. When the local handset is picked up, the Etherphone picks up the centrex line and establishes a voice path. (To completely mimic the usual telephone, the keyboard and tone generators should be active also.)

If a connection request arrives over the network, the Etherphone generates an audible ring and simultaneously keeps the calling Etherphone informed of the status of the local switchhook.

If an Ethernet connection request arrives while the local Etherphone is in use, a busy indication should be returned to the requestor. If the centrex line rings while the Etherphone is in use, the situation is more difficult. We can either implement call waiting and produce the usual beep in the local handset, or we can arrange things so that the centrex line is made busy whenever the Etherphone is in use.

We turn to a description of some value added functions that can be incrementally added to the above system without adding any hardware.

Call waiting - Rather than returning a busy signal to an Ethernet request and making the centrex line busy, we can return ringing and generate a beep in the local handset. This would mimic the PTT offering, but we could perhaps improve it by giving the local user a way to specify whether busy or ringing is to be returned. We could also give the caller the option of generating the beep only after getting a busy indication. (There is lots of room for thought!)

Call restrictions - We can easily add some non-call placement commands to the local Etherphone, like "do not disturb for X minutes" or accept only calls from certain Etherphones. Since we have no way to identify callers from centrex, only a blanket restriction could be made. This is a sensitive sociological area!

Redialing and Speed Calling - It will be simple for the Etherphone to remember a small set of numbers for single button operation and simple for it to redial the last number dialled if it was busy or no-answer.

Answering machines - Announcements could be generated, if they were short enough to keep in main memory, but more general facilities would require an audio file server.

Call forwarding - The Etherphone could be controlled from any other Etherphone or (with software) from any workstation. One could instruct the Etherphone in one’s office to forward the centrex line and arriving Etherphone calls to wherever one was. Ones office Etherphone could then automatically forward the centrex line and refer calling Etherphones to the new number.