GlobeComScript.Tioga 1. Title (Thank you, ....) On March 10, 1876, Alexander Graham Bell invented the telephone. I have some good news and some bad news. The good news is that the telephone was not invented by Thomas RyeCrisp Siren. (pause) The bad news is that, 3. Banned even though the ability to communicate, by voice, over vast distances, is one of the more valuable contributions of modern technology, some of the characteristics of the office telephone put it in a class with tobacco, alcohol, and the automobile -- objects that, if they were not already firmly entrenched in our society, would probably be banned outright by the government as hazardous to the health and welfare of the populace. What I'm referring to, of course, is the familiar litany of complaints that almost anyone will reel off if you ask what's wrong with the telephone. For instance, there's 4. Telephone Tag the infamous "telephone tag". (pause) People can go for days, weeks, or even entire careers?? without ever making contact, even if both parties actually want to talk with each other. Of course, if there's somebody you really don't want to talk to, or if a telephone call is not really convenient right now, the caller's bound to get through, 5. Interrupted ceremony as in this fanciful example. (pause) Ever notice how the telephone takes priority over the people who have actually come to see you? There's no denying that recent technological developments have begun to offer improvements. One that still needs some work is the telephone answering machine. Before showing you this next slide I must say that this situation will never arise -- in fact, our emergency telephone systems are among the real success stories -- but you've no doubt encountered situations at least as annoying as this hypothetical call to the local Fire Department: 6. Fire Department (pause) Many of the recent changes to telephone systems have made improvements in reliability, floor space occupancy, and cost. But others have actually involved new features that, if their users could comprehend them, would be truly useful. 7. Scientists These venerable scientists look like they're engaged in the discovery of some new particle, right? wrong. You know what they're saying? "An outside line? dial One First . . . . tap the receiver three times, then . . . 8. Rabbit and hat Before I succeed in offending everybody here, I have to admit that we don't have any magic solutions that will solve all these problems -- and that many very successful inroads are being made by manufacturers of telephone equipment. 9. File 10. Toolbox 11. Overview The background for this work is, simply, our experience at PARC in the development of personal information systems, primarily for the manipulation of text, graphics, images, data bases, and information that could be presented visually. One of the most important discoveries, and one that we made early on, can perhaps be paraphrased in this way: 12. A little computing What this means is that earlier computer systems perhaps produced useful results for their owners, but they were not very pleasant, productive, or supportive of their human users -- qualities that have become dubbed user-friendly in recent years. In fact, to really match the needs of the human user for the rapid display of information and the proper integration of that user's various activities requires an enormous amount of real-time computing power. This realization led us to the development, in the seventies, of workstations comprised of powerful personal computers, linked to each other and to various filing and printing services by high-bandwidth local area networks. For us, terminals like this 13. Photo of terminal provide us with our current version of this high-performance workstation. Its basic features are rapidly becoming standard within the industry: a large, high-resolution bit-mapped (or all-points addressable) display screen, a keyboard, and a mouse pointing device connected to a personal computer. If you're at all familiar with the Xerox processors, this is the terminal of one of our Dorado computers -- a very high-performance research prototype that is a descendent of our earlier Alto computer and of the Xerox 8010 Professional workstation. The Dorado is rapidly becoming the standard processor for the professional staff in our laboratory. We have developed for it an operating system and programming environment called Cedar. A typical view of a Cedar Screen 15. Cedar Screen might look like this. Very briefly, each rectangular subdivision, or viewer, presents an independent application to the user. This particular screen includes a structured text file that is being edited (in the lower left), a picture editor, in the upper left, a simple command processor in the upper right, and some specialized menu-driven applications in the lower-right. Facilities that are immediately available, but not presently in use, are represented by the suggestive pictures, or icons, at the bottom of the screen. A common approach to the interpretation of user actions allows the user to direct attention to any of the applications in any order; applications that do substantial computations can run in parallel with user actions such as text editing. With this introduction, I'd like to give you some examples of how we are beginning to use the integrated Cedar environment to improve our control over voice communications. None of the examples represents radically new capabilities; we believe their power comes from the way these facilities fit in with and draw from the existing Cedar functions. 16. Call Placement The first examples deal with call placement. In the Etherphone system, one can still just pick up the handset and punch out a phone number, but most of our users prefer to use one of the directory capabilities we've built into Cedar. Here, 17. TDir Screen I've opened three telephone-related viewers. The top one contains some general status information. The middle one is a log of recent telephone calls, including the one that I have just placed, by using the mouse to point at the desired entry in the telephone directory at the bottom of the screen and clicking a button. The system places the call, selecting a speakerphone arrangement if I don't have the handset out of its cradle. The telephone directory is contained in a large data base stored on a file server elsewhere in the local network. In fact, this simple list is just one way that the data base can be presented. 17a. Squirrel Screen Here is another, more graphical, use of the data base. (By the way, the data base system, and this particular personal directory data base, predated the voice work.) Here a portion of the data base is being presented as a sort of bulletin board on which I've placed various items that I've recently dredged up out of the data base. One of the items on the bulletin board is the picture of my colleague Larry Stewart. I've clicked at the picture using my mouse, yielding the middle viewer that lists the various things I've stored in the data base about Larry. The developer of the data base package was has added a button to this display that, when you invoke it with the mouse, will attempt to place a telephone call from my Etherphone to Larry's. The conversation Log of the previous example is now visible as the small viewer at the bottom. It indicates that I am presently attempting to call Larry. 18. Call Filtering Fortunately for Larry (and in a sense, for me, since I hate to bother the lad when he's actually working), he has been able to tell his Cedar system that he is busy and only interested in receiving certain kinds of telephone calls. 18, Filtering Screen This is what Larry's screen might look like at the time of my call. He has indicated, in the call Filter viewer at the bottom, that he is only interested in urgent calls until noon, unless they are from specific people or about specific subjects. We assume that people will use reasonable judgement about what constitutes urgent calls. Larry's conversation log, and by now my own, indicates that the call has been rejected, and why. If it's really important, I can now increase the urgency and try again. (By the way, this is the only example that has been rigged to some extent, since we are just beginning to implement the call filtering features.) 20. Leaving Message Rather than bother him, I have decided to record a voice message for Larry. The bottom viewer 21. Composition Screen on this screen is a message composition form provided by Cedar's standard electronic mail facility. It was originally designed to deliver formatted text messages, but we've recently added voice. Larry's name (as recipient), mine (as sender), and a reference to my attempted call have been filled in by the system in response to my request. I've added a subject field and a brief text message. Then I've pushed the menu button marked "Record" at the top of the viewer, and the system has instantly connected my telephone to a voice recording service. When I'm done recording, I'll push another menu button to stop recording, then another to deliver the message to Larry. 22. Receiving Message As a final example (not too effective without the sound effects, but you've done a good job of imagining them so far), we'll look at what Larry sees when he reads his electronic mail. 23. Display/Playback Screen The top two viewers on this screen are the familiar telephone status displays. The third one is a list of recently received messages, each identified by data, sender, and subject. The bottom viewer is Larry's copy of the message I sent; he displayed it by selecting the appropriate entry from the message list. Noticing that the message includes an identifier for a voice message, he uses his mouse to push the Play button in the message's viewer, and hears whatever it is I had to say to him. He can now respond either by another message (voice, text, or both), or by calling me directly. (There's no "Phone" button on this display, but there should be and soon will be, so that Larry will not have to type my name or number, or look me up in the directory.) 24. Objectives The point of these examples has been to give you an idea of the kinds of problems we wanted to solve, and the approaches we wanted to take when we began the design of the Etherphone system. We were first determined to tame the telephone: to reduce some of its disruptive qualities and improve the nature of the call establishment process, primarily by applying the display-based user interface methods we had already developed. One of the means for taming the telephone involved the flexible capture, manipulation, and playback of recorded voice. Once we had the recorded voice, we were interested in exploring other applications, such as transcription aids and voice annotation of text and graphical documents, that might also find useful application in the office. Finally, an overriding theme of this work, along with other projects in our laboratory, was to explore the increased power that integration of all of our information management tools can provide. I want to emphasize that the nature of the voice transmission or switching methods needed to meet these objectives were not among our primary goals. 25. Architecture But of course we did have to produce a system to explore these areas, so now I want to say just a little about the structure of the Etherphone system. For reasons that the paper discusses in more detail, we chose to build a local telephone system, or PABX, based on the transmission of voice as digitized packets on an Ethernet local area network. We of course also would transmit control information among the various participants using Ethernet packet protocols. We could have designed voice peripherals to fit each of the personal computer types in use in our laboratory, but for a number of good reasons chose instead to design a separate voice peripheral, which we call an Etherphone, with its own connection to the Ethernet -- more about that shortly. To keep the Etherphones relatively simple, we also rely on a telephone control server, another computer in the network that behaves more or less like a conventional PABX, except that it doesn't have to do any actual voice switching since the Etherphones communicate directly with each other. The same server machine also includes the specialized filing system that we need for recording and playing back voice messages and other recorded voice sequences. Each Etherphone will operate as a stand-alone device, but if there is an adjacent workstation, that workstation can negotiate with the telephone server to provide the enhanced capabilities I showed you in the examples. And as I've indicated, these specialized facilities depend heavily on the other systems that are already available in our network environment. 26. Architecture picture from paper This diagram reiterates the components of the present Etherphone system: from right to left, a stand-alone Etherphone that might be located in a laboratory or public area, An Etherphone colocated with one of our workstations, the server machine that provides call processing and voice storage, then a number of other network services: packet gateways, filing systems, mail systems, and so on, that complete the system. 27. Etherphone Processor The Etherphone processor itself is described in some detail in the paper. It contains two microprocessors and all the related hardware needed for the actual voice transmission and switching, for various auxiliary functions like call progress tone generation, and for the communications with the telephone server that provides the control. 28. Processor, Transmission The voice transmission components include analog switches that allow us to use the conventional telephone instrument, or a speakerphone, or a conventional telephone line, or even a stereo system, as the source or destination of the transmitted voice. We have chosen to include the existing phone line for placing and receiving outside calls in each Etherphone, for a number of pragmatic reasons discussed in the paper. Each Etherphone also includes the necessary hardware for digitization, encryption, and Ethernet transmission. Finally, we have included a number of digital signal-processing capabilities that we need to make the system work. 29. Processor, Control The remaining capabilities that are not directly associated with voice transmission include the algorithms that pass information to and receive instructions from the control server, routines that can synthesize simple digital waveforms for dial tones, ringing signals and the like, and the functions that manage the establishment and termination of voice connections between Etherphones. Finally, we needed to include ROM-based software supporting downloading of the operating programs, and low-level network-based debugging facilities that were important during the development of the system. 30. Breadboard I thought you might like to see what the early, literally breadboard, versions of the Etherphone looked like. One of these is mounted on the wall of Larry Stewart's office and serves as his Etherphone. 31. Full System The rest of us, however, have a setup like this in our offices. The Etherphone processor, in the beige cabinet (about the size of a breadbox, not a breadboard), is surrounded by the telephoone instrument, speaker and microphone, outside phone line, and Ethernet connection. To see one in operation, you'll have to come visit us in Palo Alto. 32. Summary In summary, then, we have to date built enough of these Etherphones to outfit the members of our laboratory with them. These come equipped with the kinds of basic facilities that I showed you in the examples. Our early experiments indicate that the transmission of voice using Ethernet works at least for the traffic volumes that we generate in our prototype configuration, although the long-term economic or technical viability of Ethernet transmission is not our major concern. The architecture seems like it's going to support the kinds of extensions that we have in mind for removing the rough edges from the behavior of the telephone in the office. At least the reactions of our first few users seem to indicate that we're on the right track. And we now have enough of the basics in place that we can really start to have some fun with this system. 33. Filtering Cartoon Of course, we'll have to be careful: there's no guarantee we won't also introduce some new rough edges. For instance, here's a future scenario, envisioned by my colleague Dr. Stewart, that I wouldn't wish on anybody. Thank you very much. (There is time for a question or two now, if it's pressing; otherwise let's defer them to the panel session at the end. Or whatever.) ��>�J��x�J��bx��J�� J��J�J��J��J�J��J��J�J��J��J�J��I pagebreak�� J��J��J�J�J�J�J�J�J�J�J�J�J��J��J�J�J�J�J�J�J�J�J�J��J�J�J�J�J�J�J�J�J�� J�J�J�J�J�J��J�K�J��J��J��J��J�K�J��J��J��J��J��K��J��J��^�^��J��J��J��K�J��J��J�J��J��J��K��#�#J��J��J��J��J��J��K�� J��J��J�J��J��B@E�