Because we cannot build such a stand-alone device at least until single chip Ethernet controllers are available, our immediate goal is to build a 2-5 Etherphone key telephone system (KTS) using Alto I’s and the existing Auburn audio board. We can avoid an immediate need for a telephone system gateway by retaining the current office phone lines -- rather than having a few trunks to the central office, we would have one line per Etherphone. ``Internal’’ calls would travel via Ethernet, while ``outside’’ calls, for the moment, would be placed over the existing phone system. (Think of this organization as a distributed gateway.)

We will use this initial system for development of the Ethernet voice transport protocols and call management protocols and for the development of value added functions. Our intention is that this first system be a full-time operational system (for its small community) rather than a ``demo’’ system. It is for this reason that we plan to use separate computers (not our workstations) as Etherphones. A very rough estimate for this effort might be 12 to 18 months for a few etherphones, a first audio file server, and a small heap of value added functions.

Discussion

The key telephone system proposal is a first step on the route to a full Etherphone system. We feel that the first option -- control of the existing phone system -- is unacceptable because it does not offer sufficient reliable functionality and performance. The PABX route -- control of a commercial telephone switch -- is impracticable for us because we do not have one. The third alternative, Etherphone, is difficult to pursue now because it is expensive to build an Etherphone today (although that will change).

Our KTS proposal is really a combination of the first and last scenarios. By building a few expensive (Alto I) Etherphones now, we can give a few people all the benefits of the Etherphone and develop all the required protocols and work on applications while at the same time working towards our true goal of the 20-40 chip Etherphone for everyone. In addition, the KTS idea, wherein all the clients retain their original phone lines, avoids the problem that not everyone has an Etherphone. No-ones view of the phone system need change; the same 4-digit number still works, but for those with Etherphones, many value-added functions become available.

In addition, Ethernet telephony may well be cost-competitive in a few years with a conventional PABX.

What about alternative audio hardware?

One obvious way to avoid the expensive separate Etherphone is to place audio hardware in our workstations. This approach is probably fine for annotation of documents, but our workstations are not designed for 100% availability (You can’t get calls while you are in the debugger.) and they are not designed for real-time performance (Your call to your friend breaks up because the collector starts running.) Basically, if we want to use the system while a special program is running then workstation audio hardware is fine, but we can’t build a telephone system that way -- it has to work all the time.

One way to avoid using up Alto I’s is to construct stand alone Etherphones out of commercial 16 bit microcomputers. At the present time, both the processor and Ethernet would be full boards, the audio hardware would be a few extra chips, and a fairly bulky power supply and cabinet would be needed. On top of that, we would probably not have a very good program development environment. Our early efforts would be greatly diverted by hardware and software development struggles.