Internet Telephony Lecture Notes

5 June 2008 • Voice as Data

Outline

• Introduction

• Background

• Operational Overview

• Design

• Experience and Evaluation

Manipulating Media

• Combining separate media into a new media form has long been a technological driver.

• Two problems to overcome are

  • Rendering the medium into a manipulable form.

  • Developing techniques to exploit the medium's new form.

• Digital representation solves the first problem.

The Grand Convergence

• Voice (audio) media has long been a target for manipulation.

  • Ever since Edison in 1877.

• This paper combines voice and text.

• ATM (asyncnronous transmission mode) is another technology.

  • The grand conversion of voice, video, and data.

Facilities

• The voice-management system should allow for

  Unrestricted use of voice media.
  Sharing
  Voice editing.
  Host system heterogeneity.
  Security (authorization).
  Resource management (garbage collection).

• Similar to a file system, but accounting for stored-voice characteristics.

• Voice ropes are the analog to text files.

Etherphone

• This is a LAN-based system.

Etherphone Components

• Workstation + Etherphone: Intelligence in one place, capability in another.

• The voice file server implements the voice rope abstraction for recorded voice segments.

• The voice manager provides a program (and network) API to the voice file server.

• The voice control server manages transmissions between the voice manager and Etherphones.

Voice Applications

• The intention is to treat voice as another descriptive medium, like text.

  • Record, visualize and edit voice segments.

  • Include voice segments as part of multimedia documents.

  • Vocal “clip-art” and announcements.

  • Vocal note taking (digital tape recorders).

Abstracting Voice Segments

• Voice data is stored as a linear sequence called a voice rope.

  • Text string → text rope (Cedar) → voice rope.

• Voice ropes are object-like, being refered to by a small, efficient VoiceRopeID.

  • VoiceRopeIDs can be embedded in documents.

  • A VoiceRopeID can be redeemed for the actual voice stream.

Voice Rope Methods

• Voice ropes are manipulated indirectly through API procedures.

  record(cID) → vrID, rID
  play(cID, vrID, interval) → rID
  stop(cID)
  report(rID, { started | finished | flushed })

  concatenate(vrID, …) → vrID
  substring(vrID, interval) → vrID
  replace(vrID, interval, vrID) → vrID
  length(vrID) → length

Interests

• A voice rope's class characterizes how the rope's used.

  • “E-mail attachment”, “document annotation”, or “phone greeting” classes for example.

• Voice ropes within a class are distinguished by a unique (in the class) interest.

  • The “hello” or “on vacation” interests in the phone-greeting class, for example.

The Voice Manager

• The voice manager assembles the lower-level voice-rope data structures into the voice-rope abstraction. It also provides the voice-rope API.

• Voice ropes are persistent and shared.

  • References to voice ropes must be too.

• The databases store voice-rope references and associated data.

The Voice-File Server

• The voice-file server is like a file server, but it handles time-sensitive streaming data. The voice-file server is an extension of a standard file server.

• Voice-rope data is encrypted, and handled encrypted in the voice-file server.

  • A separate data structure describes the talk-silence stretches in a voice rope.

Voice Ropes

• A voice-rope instance comprises two data structures:

  1. A file containing the voice data.

  2. A record containing information describing the voice data.

• The voice-data record information includes

  The voice-rope ID.
  Access permissions.
  Voice-data file ID.
  Voice length and interval.
  

Composite Voice Ropes

• A voice rope is immutable; modifying a voice-rope instance creates a new instance instance.

  Data are shared between the two instances.

• A voice rope made of other pieces of voice ropes is a list of the constituent voice-rope information.

  • The list is flattened to limit database accesses.

Storage Recovery

• Voice ropes are persistent; they should be kept by default.

• Voice ropes that won't be used anymore are wasteful and should be deleted.

  • Voice annotations for a deleted document, for example.

• Finding such unused voice ropes is a trick, though.

  • The system should be responsible.

Interest Counting

• The voice manager uses a modified form of reference counting based on interests.

• Each voice-rope user registers interest in the rope (via retain()).

• When no longer using the rope, the user removes its interest (via forget()).

• When no users are interested in a voice rope, it can be deleted.

Garbage Collection

• The voice manager periodically runs a garbage collector to find and recover unused voice ropes.

• The garbage collector uses interest counts and explicit queries (via garbage()) to find unused voice ropes.

  • Because ropes are immutable, finding garbage is easier than it usually is.

• New voice ropes are placed on probation for a short period to avoid race conditions.

  • A.k.a., a hack.

Implementation

• A relatively modest system supports a sizable user population.

• Statistics are fudged a bit because of the relatively artifical development environment.

  • Composing voice ropes seems a common operation.

  • Editing for size also seems common.

Embedded References

• Given the size of voice data, embedding it directly in documents is costly.

• Because voice-rope references are small, embedding them causes no difficulty with respect to size.

• However, access is being traded off.

  • Embedded data is right there and needs no further transport.

  • Referenced data has to be transported from where it's stored to where it's used.

Distributed Resource Management

• Managing shared resources in a distrubited environment is hard.

  • Accurate resource management needs precise information about the system state.

  • It is difficult to obtain precise information about the state of a distributed system.

    • One part of the system could change after its state has been recorded.

Replicaton and Reliability

• Replication is the principle way of providing reliability.

  • If one system's down, try another.

• Commit logs represent an alternative in the absence of replication.

  • If the system's not available, remember what you wanted to do and do it when the system comes back.

Performance

• Completion times for record and play are linear in the size of the voice segment.

• Encryption is expensive, in more ways than one.

• Simple and efficient databases keep simple voice-rope operations reasonably fast.

  • However, repeated opetations for composite voice-rope operations gets expensive.

• The garbage collector doesn't!

References

• Managing Stored Voice in the Etherphone System by Douglas Terry and Daniel Swinehart in ACM Transactions on Computing Systems, February, 1988.