The present CSL phone system provides a single direct dial number for each office and has a few value-added features such as call-forwarding and an attendant console. (One can forward calls to another number and one's phone transfers to the attendent automatically after three rings.) The distinguishing features of this system are that control information is ``in-band'', consisting of beeps and clicks on the voice channel, and that both voice and control information passes through conventional phone wires and through a central switch (exchange). These remarks also apply to most PABXs.

To use the transmission and switching facilities of the existing phone system and to provide control over its operation, we would build a device which would connect to a workstation and permit the machine to pick up and dial one's office phone. In addition, we would need some number of voice I/O interfaces on server machines. The voice I/O device, in small numbers, would provide a way of getting voice on and off the Ethernet, where our programs can work with it, file it, and so on. The A/D and D/A conversions are provided by a server, rather than by one's own voice terminal.

This system provides the capability for a number of really impressive systems: voice messages, voice annotation of documents, semi-automatic call placement, and so on. There are also some crippling disadvantages. Any voice recording or playback would require placing a call to one of the servers! Calls are placed by electrically picking up the office telephone and electronically generating beeps. This can be made to work, but is a slow and somewhat uncertain process. The progress of an attempted call is determined by the return of various noises over the voice path: ringing, dial-tone, busy, fast busy, etc. It is quite difficult for a machine to sort out these noises; they cannot be ignored because calls do not always get through. In addition, the placing of a call requires several seconds: one or two to dial the call, perhaps one for the system to connect a local call, and as many as six seconds for ringing to be detected at the destination. This means that for applications such as annotation of a document, one's office phone is effectively tied up since we could not afford the overhead of setting up a call for playback of a 10 second segment.

Many of the call placement and call receipt functions, for calls within the system, could be handled by internet communication, one's workstation could check if the callee's phone was in use before placing a call. There would still be a small "window" through which other calls could creep. Functions like complex forwarding would be quite difficult, since we could use only the switching capabilities built into the standard phone system.

The essential difficulty with use of a standard telephone system is the lack of sufficiently fast and versatile control of the switching machinery.

Belleville is essentially following this strategy. His voice box is an audio interface for a workstation. His device includes a tape recorder so that low power workstations can control the operation of the voice peripheral without handling voice data directly. Higher power workstations also have access to the digitized voice.

We could replace our present telephone system with a commercial PABX and use one of our own computers to control it. D/A and A/D conversion functions for manipulation of voice-as-data would be done by servers, and call placement would be be done either by manually dialing one's telephone or by having one's workstation instruct the control computer to set up a call.

In this system, the voice data still travels through more or less conventional wires and switches, but the control information is entirely digital, on the Ethernet, and under our control. Calls inside the PABX would be very fast and we would have easy access to the state of the system. It would be possible to connect to a server for just a few seconds to record a voice annotation, while still remaining available for incoming calls. Complex switching operations would be possible because the phone system would be entirely under our control. We would still require an adequate number of servers to meet our D/A and A/D needs.

The key disadvantages of this system are that we do not have such a controllable PABX and, before installing such a system, we would have to negotiate control of the switch with the vendor.

If we build our own transmission and switching, we will clearly have sufficient control over it to supply the facilities we need. The possible approaches lie along the spectrum from constructing a more or less conventional telephone switch to a fully distributed architecture of telephones connected to a local network. In our environment, the local network of choice is the Ethernet -- we call this approach Etherphone. Somewhere in the middle of the spectrum are systems with multiple line controllers connecting 8 to 32 telephones each to the Ethernet (or interconnected with high speed lines).

One might call the three approaches to contruction of transmission and switching facilities the centralized, the hierarchical, and the distributed. Construction of a standard telephone switch lies largely outside our expertise. The hierarchical approach of shared Etherphones is described more fully later, but briefly it might be a bit less expensive in trade for a larger and more difficult design. For these reasons, we are concentrating on Etherphone.

Discussion

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 Etherphone approach is the only alternative which provides sufficiently versatile transmission, switching, and control capabilities and which is available to us. At a later time, we may wish to integrate both hierarchical and "centralized" components into the transmission and switching system. If we do a good enough job with the control protocols for the system, such integration may not be too difficult.

SHARED VS. SINGLE LINE ETHERPHONES

This is a series of notes by Stewart on this general subject. Dan Swinehart's comments marked (DCS).

The shared Etherphone is thought of as a Dandelion class machine without a display or disk, but with a highly capable Ethernet controller and a capable T1 style TDM interface. Belleville's rough estimates place such a design at about $200 to $300 per line. Thacker has suggested that a shared controller might be more reasonable than single line micro based Etherphones.

(DCS) In a "third generation" system, I'd expect most of the functions of the Etherphone server to have drifted back into the Etherphone -- or at least into one Etherphone on each cable -- so that cheap systems could be made and sold. The memory, esp. program memory, will then have to be somewhat larger. I believe your memory sizes within a factor of two or so, for the Etherphone II (one for everyone in CSL, but still not a product).

(DCS) To build the Etherphone II B, one needs a reasonably powerful keyboard and some kind of alphanumeric display. That is easier if there's a processor nearby. The T1 time slot scheduler for all this stuff could get pretty hairy.

However, if we go with the single line Etherphone, we (CSL) might never build a POTS gateway because we may not be able to put it to much use without divorcing ourselves from the Xerox Palo Alto phone system. (If we eventually go for replacing that system we would have more resources to use to build the POTS server.)

a) Don't forget, though, that coax is much cheaper than transceiver cable. We could afford to let the coax lie in loops in order to get the tap points where we want them.

[Hardware] It seems much easier to design a microcomputer out of standard parts on a single board than to (say) take apart a Dandelion and replace the display controller with some kind of T1/button/lights interface. (If we build a Dolphin board, the economic justification for building the shared device vanishes, yes?)

[Software] The shared controller must handle over 400 packets per second for 8 simultaneous users. There are laws of large numbers for concentration of telephones but 8-24 phones doesn't seem like enough to get much advantage. It is harder to write the program.

Part of the same picture is that the shared controller is more complicated. We don't know just how many conversations a given machine could handle, and the economics (see below) are critically dependent on this number.

a) The codecs and analog electronics come out about even.

b) You need a certain amount of ram per conversation, plus additional ram for the more complicated program. The shared machine can use larger cheaper dynamic memory chips though.

c) The program memory scales less than linear for the shared Etherphone, but its size does increase. (DCS) The shared Etherphone memory would have to be much faster stuff for the faster processor.

d) In trade for multiple Ethernet controllers and transceiver cable interfaces, the shared Etherphone needs multiple cable drivers for the T1 loop.

e) The power supply has economies of scale, as does the box (but don't forget that all the phones have boxes too, and that eventually the single line Etherphone could fit inside.) (DCS) The phone box will probably need more power than can be sent down the loop cable anyhow. A speakerphone does. So do most keyboards, displays, etc.

f) The T1 interface stuff is not that small, especially since the button and light information needs to be handled.

g) You need a certain number of processor cycles per conversation, plus a few to run the more complicated program (scales more than linear!).

h) You might use a common encryption unit instead of distributed, but this requires doubling memory bandwidth, plus setup time etc.

(DCS) If we were convinced that a non-shared EP could never be made economically feasible (favorable or neutral), I think we'd have to look at some other architecture. We are not convinced of that. It is more important to explore a design whose architecture looks superior when evaluated by any standard other than cost. I think, for us, that's the non-shared EP.

(DCS) Samples from all conversations from a particular shared EP could be sent in a single packet, using multicast techniques. This would cut contention and overhead even more, at a cost of some hairy descrambling in all receivers. Silence detection, over short intervals anyhow, becomes useless in such a system. It's all very hairy.