Outline Abstract Notes: paper has goal of defending notion of layered architecture for voice; is mostly a systems description. Is hardly "easy", as it stands. It doesn't capture (multi-media) theme directly. Introduction Argument for Architecture Typical sequence: monolithic applications, closed architecture, open architecture Process retarded in voice, since functions "well understood already" Lip service to integration: present systems either link-level integration or monolithic Goals of Etherphone project in those terms Initial Etherphone goals -- standard arguments Importance of voice Need for integration Need for progress in taming, managing . . . Evolutionary goals: architecture (see voice position paper) Specifications for programmers Specifications for vendors Argument about need to accommodate many different kinds of things Evolution Choice of vendors based on primary contribution, then want to play. Central Intervoice Elements Environmental stuff Workstations in internetworked environment. Many kinds of workstations Need for single voice path (Nature of medium) separable from WS for all functions RPC is the unifying factor. Thrush Nucleus -- conversation manager (this is the pre-Thrush 7 purist view; still not happy with Thrush 7, abstractly speaking) Abstraction: parties, conversations, implementations Notes: motivation: independent behavior for different participants. Must cooperate to get the right thing to happen, but primarily need is ability to "hang up" Notes: motivation: maintain the "truth" about conversations, in env. with multiple players.; make avail. Similar to MVC and Cedar painting. Notion of party to conversation Represents participant in conversation (person, service) Represents single source and/or sink of voice information No direct indication of how implemented -- no information at this level about what hardware is like, what's purpose of this party, .... Notion of conversation Way of representating connections among parties. All active parties can hear everything generated by all others, generate to all others (both options) Examples of states, including multiply-active parties (private listening to server) Implementations All parties, but radically different nature, client/user interface, connection behavior. Examples: telephones, outside telephone lines, synthesizer, voice recording, voice recognition, music maker, local noise sources Multiple impls can share behavior of party Example: Workstation and telephone -- remind of reason: independence. Notes: Interesting that services and user applications have similar structure in this architecture (Lark Smarts, Bluejay Smarts) Conversation manager controls: Creation of convs. Admittance into convs. Advancement of states Reports of significant events (states, impl-generated events) to implementations Support for flexible mappings among parties and implementations; allows poaching and visiting. Notes: want cloud model of architecture here, with Thrush in the middle. Notes: Not comfortable with level of detail of switching architecture. How to generalize? Registration of specialized services: Per party. Other parties may obtain information needed to perform specialized Databases General key-value databases. Directories Map phones to workstations, people to phones and workstations Long-term Short-term (visiting and poaching) Names to numbers for outside calls. Store profile information Long-term Short-term Basis for management of recorded voice. Critical applications Really implementations, but have to be there or system not very useful. Telephone implementation Stand-alone behavior of telephone instrument. Cooperation (impatient) with workstation implementation. Trunk implementation Management of telephone trunks or lines. Application Examples Workstation implementation Shared implementation of party behavior for telephone instrument. Synthesizer (the good ones will be somewhat expensive for a little while) Voice Ropes/Voice Server Recording/playback implementation, as a party Management of editing operations, through specialized interface. Speech recognition services (the good ones will be expensive for a while) Workstation applications Voice Editing more elaborate transcription aids. Telephone control, logging, databases, ... Narrated documents. Protocol recording for Specific Architectures Ours Etherphones, shared servers, voice transmission protocols. Notes: show physical picture, showing where clouds fit around the architecture. Evolutions Fully-distributed Thrush, no server. Different Built in/on top of conventional PBX. Can still accommodate LAN-connected workstations Extensions Accommodate, at least partially, Centrex. Combine any or all of above. Conclusions Architecture is a good idea. Ours is providing interesting results. More work needs to be done Simple things simply, everything possible. Summary and wrap-up. ŽIEEEOutline.tioga Swinehart, September 29, 1986 1:01:47 pm PDT How to model a private aside among two participants in a four-way conv? ΚΚ˜code™K™,—head˜L˜IindentšΟs#Πesœ–˜ΐ˜ ˜M˜QM˜DM˜W—˜*˜.M˜M˜M˜+—˜;M˜M˜˜AM˜ M˜C————˜˜M˜+M˜˜M˜M˜M˜—M˜—˜&M˜ZM˜4Mš ˜ MšŒ˜Œ˜M˜8M˜9M˜‡—˜M˜0M˜eM˜SM™G—˜M˜XM˜€˜*M˜E——Mš€˜€˜M˜M˜M˜M˜PM˜^—MšH˜HMšZ˜Z˜%M˜ M˜B——˜ M˜˜ ˜=M˜ M˜"—M˜#—˜M˜ M˜ —M˜'——˜M˜G˜M˜-M˜8—˜M˜(——˜˜M˜A—L˜I˜M˜-M˜@—L˜I˜M˜ M˜"M˜*M˜M˜——˜˜M˜:MšO˜O—˜ M˜$—˜ M˜V—˜ M˜)M˜——˜ M˜M˜&˜M˜*—M˜—M˜——…—"z