IEEEOutline.tioga
Swinehart, September 29, 1986 1:01:47 pm PDT
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)
How to model a private aside among two participants in a four-way conv?
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.