5/12/98 1

PML: A Language Interface to Networked Voice Response Units

Discussion for ATS’98Chris Ramming

AT&T Labs West

5/12/98 2

Outline• Background

– IVR Applications (the relevant domain)

– Project Objectives

– IVR Architectures: CPE and Network

– Challenges of a service-oriented approach

• The Phone Markup Language (PML)

– Goals

– Description

– Effects

• Demo

5/12/98 3

Interactive Voice Response (IVR) Applications

• Transaction-Oriented IVR Applications

– Bank-by-Phone, movie ticket purchase

– Email-by-phone, PIM-by-phone

– Stock quotes, news, weather

• Communication-oriented IVR applications

– “Find me” applications / enhanced answering machines

– Conference control

• Transaction/Communication mixtures– Personal telecommunications assistants

5/12/98 4

Project Objectives• Explore idea of language-as-network-service

interface• Integrate the Internet and PSTN• Build Interactive Voice Response (IVR)

systems with well-known architecture, languages, and protocols

• Transform IVR industry from customer premise industry to network service industry

5/12/98 5

A Customer-premise VRU

VRU Owner

Voice Response Unit (VRU)

+Application Logic

+Application Data

Applicationprogramming/admin

Callers

5/12/98 6

Disadvantages of customer-premise VRUs

• High startup costs for the purchase of VRUs

• Fixed, costly PRI connectivity independent of utilization levels

• Must address low-level VRU programming and architecture in addition to application detail

• Responsibility for (7x24?) reliability

• Must be responsibility for equipment maintenance & upgrades

• Limited, fixed capacity for any installation

• Dynamic routing (in case of disaster) difficult

5/12/98 7

Advantages of IVR as Network Service

• No specialized equipment investment

• No fixed expenses for PSTN connectivity

• Can focus on content/application rather than low-level VRU detail

• Offloaded responsibility for 7x24 reliability

• No need to be concerned with equipment, software upgrades.

• Possibility of flexible capacity

• Location transparency of VRU permits dynamic routing

5/12/98 8

A Separation of IVR Concerns

Application Programmer

App. Logic&Data

Voice Response Unit (VRU)

ApplicationProgramming/Admin

Callers

5/12/98 9

IVR Separation of Concerns

• VRU-side– Call control (answer,

hang up, transfer, etc.)

– Speech synthesis

– Audio playback

– Audio recording

– DTMF detection

– Hangup detection

– Speech recognition

• Application-side– Application logic

– Application data

5/12/98 10

The PhoneWeb Architecture for IVR

HTTP Daemon serving

PML

Telnum/URLTable

VRU containing

PML Interpreter

PSTN

Internet

CallersApplication Programmer

5/12/98 11

Challenges of IVR as network service

• Reducing cost through timesharing of VRU• Guaranteeing VRU integrity

– careless application programmers– malicious application programmers

• Guaranteeing application security– no way to access other applications’ data

• Obtaining efficiency in a distributed application• (Helping customers build effective services)

– conforming to useful conventions

5/12/98 12

PML ideas• PML only handles content output, form-based

user input, and call control; arbitrary “service logic” is performed at the HTTP daemon via CGI scripts or other means.

• PML is a finite-state-machine language.– VRU activity is event-based

– FSMs permit useful dynamic and static analysis

• PML syntax is a variant of HTML (controversial).

5/12/98 13

Visual Web vs Phone Web

• Text-to-Speech, Audio• DTMF, ASR, Audio• Handset Speaker• Mostly transaction svcs• Call control• Stateful presentation

• Text, Images• Keyboard, Mouse• Screen• Some transaction svcs• No call control• Stateless presentation

5/12/98 14

PML, an HTML variant

• Output

• Control constructs

• Input

• Call control

• Exception handling

• Application debugging & analysis

• Interaction definitions

5/12/98 15

Result: Efficiency of distributed IVR applications

• Mobile code allows a quantity of computation to take place in the server

– In IVR applications, interactions with user are very time-sensitive.

• Mobile code may reduce the overall amount of data transmitted

– as in PostScript

• Restricted language permits interesting optimizations

– Pre-fetching and caching of Web pages

5/12/98 16

Result: integrity of the shared VRU

• Allocation, Deallocation, and invocation of resources such as TTS, ASR, processor, etc. is correct by construction, analysis, and dynamic guards

• If language interpreter cannot harm VRU, neither can any application– sandboxing of interpreter is an additional

possibility

5/12/98 17

Result: Application security in the shared VRU

• PML provides no constructs for referring to underlying operating system resources or the activity of other application instances

• Security problem reduced to security of interpreter, not that of arbitrary applications

5/12/98 18

Unsolved problems / Future Work

• Eliminating interpretive overhead– Partial evaluation

• Thibault et al use partial evaluation and achieve 100% of C code performance in an active network setting.

– Proof-generating compilation• May be possible to compile PML at client and

automatically instrument it with necessary proofs• Eliminating noncritical application bugs

– PML is based on FSMs• May be possible to statically verify application-specific

safety properties.

5/12/98 19

Conclusions• Restricted languages are suitable interfaces to shared network

resources.– Restrictions can be leveraged for automated optimizations

(prefetching, resource allocation)– Restrictions can be used to prevent insecurities (unsafe

operations not part of language) and permit timesharing– Restrictions can lead to efficient implementations of

untrusted code – Language interfaces are appropriate in a distributed setting– Mobile code reduces network interactions and possibly

bandwidth