ABSTRACT

INTRODUCTION

VISIONARY OVERVIEW

New User Services

Benefits to the Callee

Benefits to the Caller

A Potential Benefit for Both - a Locator

Voice Messages

Integration with Regular Telephones

Background and Discussion: Three alternative approaches

1. Centrex

2. Control of a PBX

3. Etherphone

Discussion

PLANS

Etherphone I

Requirements

1. Processor/Memory/Ethernet
2. Audio hardware/audio switching

3. User interface, buttons/lights/display

Proposal

Details of the Etherphone I

Hardware

Functions

Bit transport

Supervision

Making connections

Placing a call

Receiving a call

During a call

Enhancements

Call waiting

Call restrictions

Redialing and Speed Calling

Answering machines

Call forwarding

APPENDIX - THE MICROCOMPUTER BASED ETHERPHONE I

1. Hardware

2. Software



Hardware stuff

Fig. 1 shows a block diagram of the sort of intermediate range system we are contemplating. The Etherphone is a "smart" telephone, containing a computer with a modest keyboard, a one line display, ethernet interface, speaker, etc. It digitizes analog data and ships it (as well as call set-up control information) over the ethernet instead of over the usual phone wires. Typically the receiver will be another Etherphone, participating in a call set-up or an on-going conversation. In the latter case the receiving Etherphone simply reconverts the digitized voice (from the ethernet) back to analog form and feeds it to the handset. Sometimes, as discussed below, voice traffic will go to or come from an Audio File Server which embodies special real-time capabilities necessary for servicing voice messages.

The Etherphone, is logically free-standing. Telephone service must continue to be provided even during times when one’s workstation is otherwise occupied -- we don’t believe in the "always-ready-to-help" workstation. The Etherphone will provide some phone services without any help from the user’s workstation although we expect the workstation display to provide many of the advanced user interfaces. Certain functions, such as name-lookup, assistance in managing (negotiating) connections, etc. may be provided by a separate Etherphone Server. The exact division of labor between the Etherphones, workstations, and the Etherphone Server is not yet clear; the purpose of the server is to allow us to keep down the size of the Etherphone itself by sharing low duty-cycle functions.

For an individual who has a workstation, software that works in conjunction with the Etherphone and Audio File Server would allow one to listen to (receive), construct (edit), file, and transmit voice messages (or other voice documents for that matter). For these applications, think of the Etherphone as a peripheral that happens to connect to the workstation through the ethernet. Naturally, for a user with just an Etherphone, we would use the one line display to present voice messages.

Our plans call for a phased compatible growth into this new world. During this process there will be old-style phones (in CSL and certainly in the "outside" world) with which we will need to communicate. That means we will (eventually) need a POTS gateway (plain-old-telephone) which allows conversations between our system and the regular phone system. For the moment, we plan to reatin the individual office phones as a kind of distributed POTS gateway.

To summarize, the eventual system includes the following elements:

1. Etherphones
2. Etherphone Server
3. Voice File Server
4. Related workstation programs
5. POT Gateway

A probable order of implementation might be 1, 3, 4, 5, 2, and then 1 again, as we build the small, cheap Etherphone II.



ADDITIONAL STUFF NOT YET ABSORBED:

Given that you have decided to pass real time voice via the ethernet, the reasons you need to have a special phone-computer (other than your work-station) are:

1. There will still be stand alone phones (no workstation) with which you must communicate

2. Your worksrtation won’t be smart enough (for many years if ever) to be available for handling phone calls with the sort of availability you expect and need for your phone.

3. There will be diversity of machines and you don’t want to have to build sixteen different kinds of hardware

So why pass real time voice over the Ethernet?

1. If you continue to use the PTT, then you will constantly have to adapt to their changing rules - you will be using signaling techniques and protocols not under your control

2. Ethernet is cheaper for people who aren’t already committed - it (time multiplexing of packets) is the wave of the future even for the phone company (?)

3. Call placing and receiving is smoother - and faster.

4. There are some features you can’t get by the "low-rent" arrangement

1. conferencing

2. Intercom - because call setup is quicker and you might re-establish connection whenever voice speaks - that lets you use the phone for other uses while also doing low-duty intercomming

3. phone busy - let you carry on several conversations at once - like sequencing extensions but without any special hardware

5. Serendipity

6. Fun

Reasons not to pass real-time voice over the Ethernet:

1. There will be delay problems for sure

2. There may be some bad delays - e.g. Dorado file transfers - if we don’t use a separate voice ethernet

3. Capacity uncertainty - Gateways

4. Costs more (the computer you need is bigger - more buffering - although you don’t have to pay for the PTT

5. You still need a special computer to pass Ethernet voice out into the outside world of the phone system

6. "We don’t understand the problem" - the Phone Co. does

7. Echo supression troubles